On 19 January 2015 at 05:08, Bohuslav Kabrda <bkabrda@xxxxxxxxxx> wrote:----- 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 issues that come up are if ring0 and ring1 has a different update process than ring2. If an SRPM has both in them, then you may not be able to fix problems in ring2 because ring0, ring1 would supercede ring2. Thus you end up splitting out a lot of packages into sub-rpms to deal with what the developer sees as needless bureaucracy but the 'product manager' does not.
Yeah, I meant that either
a) the process shouldn't be different, at least from maintainers point of view - in other words, maintainer would work as he now does, but the package would be tested (for example in Taskotron) and bugs would be reported
or
b) if at least one binary RPM produced by a SRPM would be in 0 or 1, then all others should be there as well (making ring 1 defined by SRPMs, not RPMs)
Since b) has a potential of significantly expanding ring 1, I'd vote for a). But again, that's my perception of this all, I'll make sure to bring this topic up on next Env & Stacks meeting, so that others express their opinions as well.
Slavek
--Stephen J Smoogen.
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
