Re: Modularity and the system-upgrade path

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Oct 13, 2019 at 10:48 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote:
>
> On Sun, Oct 13, 2019 at 08:01:45PM +0200, Miro Hrončok wrote:
> > On 13. 10. 19 19:38, Kevin Kofler wrote:
> > > Ben Rosser wrote:
> > > > Before things are rolled out further, I'd like to see some policies
> > > > agreed upon for what modularity is and isn't allowed for in Fedora:
> > > > what are the rules for default streams, buildroot only modules,
> > > > modularizing non-leaf packages, etc.
> > >
> > > So, to start that discussion, I think all 3 of those should be no gos in
> > > Fedora. In other words, I propose the following rules:
> > > * no default streams, use "ursine" (non-modular) packages for the default
> > >    versions instead (you may ALSO ship the same version as a module, if that
> > >    makes it easier for you, i.e., if it means you don't have to retire and
> > >    unretire module versions at every release, but the "ursine" version must
> > >    exist),
> > > * no buildroot-only modules nor buildroot-only packages in modules,
> > >    everything used to build packages must be shipped along with them,
> > > * no non-leaf modules, since those unavoidably lead to version hell due to
> > >    the non-parallel-installability of different versions of the same module.
> >
> > The third rule is unnecessary with the first. We can keep the integrity of
> > the default and provide non-defaults that may violate it if properly
> > documented (you might want to enable a nondefault modular stream to install
> > libfoo:0.27 in a container, even if it makes various packages you don't need
> > noninstallable).
>
> I was hoping to have some of the folks who would be saddled with tons
> more work if this policy was enacted chime in, but I don't think any of
> them have. (ie, the people who have moved their packages to modules and
> have or are going to retire their non modular versions). We may want to
> ask them directly what they would do if this policy is enacted.
>
> I understand that people want to go back to the last known "good" state
> for them and regroup, but keep in mind that has it's price also. One
> that I don't think too many in this thread will have to pay, so it's
> easy to just say 'revert it all'.

>From what I can tell, the only two package groups that are really
affected by a move to "modules only" are java and eclipse.
If that's correct, "revert it all" would only affect eclipse so far,
because it now has broken dependencies in non-modular fedora.

But we (the Stewardship SIG) have been maintaining over 200 packages
in the Java stack since their original maintainers either were
declared unresponsive, or abandoned things for "greener" pastures in
modular branches. We've managed to cut the number of outdated packages
from over 60% to under 40%, and still pending updates bring that down
to about 25%. So I'd wager that the non-modular Java packages are now
(or will be soon) in better shape than their modular counterparts ...

Fabio

> kevin
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux