On Thu, Oct 24, 2019 at 4:31 AM Lukas Ruzicka <lruzicka@xxxxxxxxxx> wrote: > > As far as tooling is concerned, I have been seeing complaints about DNF doing a bad job, but from the perspective of acceptance > testing, it's the DNF operations that usually work fine with installing, enabling, disabling, removing, resetting and switching modules and streams. > > 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. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
