[Proposal] Ring-based Packaging Policies

Michel Alexandre Salim michel at michel-slm.name
Fri Feb 13 09:39:52 UTC 2015

On Fri Feb 13 2015 at 2:02:27 AM Colin Walters <walters at verbum.org> wrote:

> On Thu, Feb 12, 2015, at 01:32 PM, Stephen Gallagher wrote:
> > tl;dr Shall we consider requiring a lesser package review for packages
> > that are not present on Product or Spin install media?
> It's worth noting here that having two levels is not really going
> to be new to the ecosystem; e.g. Ubuntu has had Main/Universe
> for quite a while:
> https://help.ubuntu.com/community/Repositories/Ubuntu
> I just have one question: You're defining this split at the *runtime*
> level.  Last I saw the Base working group was trying to cut down
> BuildRequires
> (but sadly I haven't seen them fighting Requires yet - I would love
>  if someone did that for Perl)
> If Ring 0 packages BuildRequire Ring 1 (or further)
> packages, ultimately their quality is going to be somewhat contingent
> on them.  Using bundling as a differentiator though, it does seem
> like there's likely a lot less pressure to require quick security
> updates for BuildRequires.
> Anyways, something I think is missing from here is more
> details on how this "on the install media set" distinction
> is maintained over time.  If it isn't separate (yum) repositories
> it seems like it's going to be hard to enforce.
> (Who would notice if a package in 0 started depending on a ring
>  1?  Would that imply the new dependency needed another
>  review pass?)

Having bumped into bundled library issues in the past, this to me sounds
like a good idea... provided exclude libraries at the beginning.

So: this should only leaf packages, plus applications that happen to have
add-on packages that depend on them, and only those that are not Ring 0
(not shipped in one of the install media).

A nice alternative is to use the staging area we talked about for this Ring
1 category.

Best regards,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150213/4b377073/attachment.html>

More information about the devel mailing list