Meeting minutes for Env-and-Stacks WG meeting (2015-01-14)

[Kevin Kofler]

Bohuslav Kabrda wrote:
> Please note, that this proposal is absolutely not about imposing some
> restrictions on who can/should maintain what. It's really just a
> categorization of packages based on our WG's perception of importance to
> Fedora.

Sure, but there is still a distinction in that proposal between first-
class/Core (ring 1) and second-class/Extras (ring 2) packages. Even without 
the political/maintainership issues that the old Core/Extras split had, 
there were also some technical issues, which this proposal is reintroducing. 
Those stem from the requirement that ring 1 be self-hosting. It means that 
not only everything required to build ring 1 packages must be in ring 1, but 
also everything required to build optional subpackages of ring 1 package 
SRPMs! In practice, this means that either, e.g., large portions of TeXLive 
end up in ring 1, or we end up having to disable features, documentation 
etc. for several packages, or build them as separate SRPMs (which is always 
painful; we try to avoid that for a reason).

For those not familiar with the issue from the Fedora Core past, just have a 
look at EPEL, where the split still exists. We end up with hacks like a kde-
plasma-nm-extras SRPM that builds some plugins for the kde-plasma-nm package 
in RHEL (those that depend on VPN libraries not in RHEL and thus cannot be 
built in the RHEL package). Such an -extras package then typically needs to 
track the base package exactly, making updates painful (requiring 
coordination). (This would be much more of a problem in the fast-moving 
Fedora than in RHEL with its extremely conservative update policy.) We also 
end up with RHEL's KDE applications having many optional features simply 
disabled (at compile time), with no way to add them (other than replacing 
the entire packages with ones built with the optional features enabled from 
a third-party repository, in this case Rex Dieter's kde-redhat).

IMHO, such a self-hosting "ring 1" is a step backwards, even if the 
implementation keeps it open to all Fedora packagers.

(The "ring 0" is likely subject to similar issues and I'm not convinced we 
need that, either, even though a self-hosting minimal system has been 
proposed for a long time.)

        Kevin Kofler