[Proposal] Ring-based Packaging Policies

[Josh Boyer]

On Thu, Feb 12, 2015 at 1:32 PM, Stephen Gallagher <sgallagh at redhat.com> wrote:
> == Proposal ==
> With these things in mind, I'd like to propose that we amend the
> packaging policy by splitting it into two forms:

I think this needs to go beyond simple policy.  It needs some
buildsystem enforcement as well.

> === Core Packages ===
> Any package that is provided on a release-blocking medium (which at
> present includes Fedora Atomic, Fedora Cloud, Fedora Server, Fedora
> Workstation, the KDE Spin and several ARM images) must comply exactly
> with the packaging guidelines as they are written today. These packages
> must receive a full package review *when they are added to the install
> media*. Any package present on the media if this proposal is adopted is
> exempted from this requirement. Any package to newly appear on the
> install media after this time *should* (I hate that word...) receive a
> new package review, even if it is already present in Fedora.

With the definition you have here, I'm afraid we are going to be
constantly playing "is or isn't" on whether a package is core or not.
E.g. things get sucked into the install media due to dependencies and
nobody notices until it's time to trim the size.  It just doesn't seem
like this would scale, particularly since the distro is rather fluid.

Perhaps instead the Base WG could come up with what they consider
core, and we could really stick to that?  Meaning, things in core
cannot Require packages outside of core at runtime.

> === Ring Packages ===
> Any new package that is *not* going to be part of the install media set
> is required to pass a lighter review and is permitted to carry bundled
> libraries, with caveats to be listed below.

I'm OK with this if Ring packages land in a separated repo.  That
could be done by having a separate koji target that spits out things
into a rings repo.

My concern here is that if everything (ring and core combined) lands
in the same koji tag and goes through koji just like packages do
today, we're going to wind up with a big mess.  Having dependencies on
ring packages is going to entangle things and make it very hard to
clean up later.

> ==== Ring Package Review Requirements ====
> * A reviewer *MUST* establish suitability for the Fedora Project. This
> means verifying that the package contains only permissible content
> (legally-speaking).
>
> * The package *MUST* conform to the FHS and other filesystem conventions
> used by Fedora (such as %{python3_sitelib}), except when granted an
> exception by the FPC.
>
> * The package *MAY* contain bundled libraries or other projects, but if
> it does so, it *MUST* contain a "Provides: bundled(pkg) = version" for
> each such bundling. This is done so that we can use the meta-data to
> identify which packages may be vulnerable in the event of a security
> issue.
>
>
> == Conclusion ==
> So that is my proposal to consider for Fedora 23+ (it's too late in the
> Fedora 22 cycle to consider this, but I'd prefer starting the F23
> discussion right away). Comments and suggestions are strongly
> encouraged.
>
> Thank you for reading to the end.

I don't think the proposal is a bad start, but I'm concerned it isn't enough.

What I would really like to see if a proposal that focuses on the two
different needs: 1) packages that are used for the Operating System
(the distro/OS) 2) packages that run on the OS (Apps?).  Packages that
are used to create Fedora itself should by most definitions wind up
being Core packages in your proposal here, regardless of whether they
are on install media (pretty sure gcc should be core...).  Packages
that people want to run on top of Fedora could be the ring set.  Some
might call that "Core+Extras" but that isn't my intention.  Packages
in the ring set could move to core easily once they are cleaned up and
meet the existing FPC guidelines.  There is also no separation of
schedule or dist-git or buildsystem or ACLs.

Really, I would like to see the Ring set of things not be RPMs at all.
RPMs are system wide installation.  I know Dan Walsh would say that
containers do not contain, but the security model around them is
slightly better than blasting an RPM that bundles a bunch of stuff
onto the entire system.  However, there is significant technical work
for that to be feasible and it isn't clear that there is a container
technology that is well suited for non-network apps yet.

josh