----- 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
