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

[Stephen John Smoogen]

On 19 January 2015 at 05:08, Bohuslav Kabrda <bkabrda at redhat.com> 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.


-- 
Stephen J Smoogen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150119/918b2440/attachment-0001.html>