Neal Gompa wrote:
On Thu, Oct 24, 2019 at 4:31 AM Lukas Ruzicka
<lruzicka(a)redhat.com> 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