Re: Modularity and the system-upgrade path

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

 



Neal Gompa wrote:

> On Thu, Oct 24, 2019 at 4:31 AM Lukas Ruzicka <lruzicka@xxxxxxxxxx> wrote:
>> I believe, that if modularity was opt-in, we would be able to use it just
>> fine, as it is designed now with some little tweakings, such as DNF
>> providing enough info on retired or discontinued streams, offering a
>> possibility to choose a different stream to switch to on upgrades. The
>> longing for default modular Fedora is what makes it more problematic,
>> because we need to hide everything from the users and make everything
>> work automatically. If modularity was a matter of personal choice we
>> would not have to hide anything from anybody, because those users would
>> be able to read the necessary documentation and tweak their systems just
>> fine.
> 
> Unfortunately there have also been major performance regressions
> because of the additional work to handle modules being default
> enabled. The current handling of modules in DNF is not cheap. I'm not
> sure if this is because it uses libmodulemd1 vs libmodulemd2 or if
> it's because modules aren't implemented at the libsolv layer and can't
> be computed as part of the initial constraint set through the base
> solver. But whatever the reason, it is markedly slower than on systems
> that don't have modular repositories at all.

All these are convincing technical arguments for disabling Modularity by 
default from F32 onwards. (It is unfortunate that these have not been 
considered for the existing releases, but we cannot turn the time back, we 
have to focus on improving things for the upcoming releases, hence "from F32 
onwards". I would even propose it from F31 onwards, but I do not think FESCo 
is willing to delay the F31 release long enough to implement the required 
demodularization upgrade path in DNF, hence F32.)

        Kevin Kofler
_______________________________________________
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