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

[Bohuslav Kabrda]

----- Original Message -----
> 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).

I personally don't have a problem with putting large portions of TeXLive into ring 1. Again, I have to repeat that this is only a categorization of a state that currently exists with no intention of changing it (except perhaps suggesting that the ring 0+1 packages get more QE, perhaps in Taskotron).

> 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.

It's not. I don't see why we would need to do such hacks as are done in EPEL. The way I see it, if kde-plasma-nm builds several binary RPMs, then some of them are on LiveCDs, hence in ring 1, while others are not (=> ring 2). And there's no problem with that. Or is there?

> (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

-- 
Regards,
Slavek Kabrda