On Tue, Oct 15, 2019 at 11:22 AM Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
On Tue, Oct 15, 2019 at 12:36:15PM +0200, Miro Hrončok wrote:
> >As package maintainers we all make technical decisions which have
> >significant impact on our users every day - whether that's in the choice
> >of defaults, choice of build flags, or whatever. Honestly delivering as
> >modules-vs-non-modules is a completely trivial issue compared to most of
> >the stuff I spend time on. If "yum install X" still works most
people
> >just don't care about the RPM/dnf/repo mechanics behind that.
>
> Except it works only half way. The installation works. Later,
> dependencies are broken. Upgrades are broken. "yum remove X" does
> not undo the action completely.
>
> The main issue is: user just enabled a module without doing it
> explicitly. The user needs to know how to handle modules in order to
> recover.
I never expect "yum remove X" to be the inverse of "yum install X".
DNF's
magical leaf tracking makes it a bit more so, but not exactly. So, I don't
think we should make that a very high priority concern (although if we can
improve it, so much the better).
Upgrades need to work, though. And they need to work regardless of whether
we ban default modules or not. So, given that, I'm not _really_ seeing big
differences in practice for the user beteen these two proposals, and the one
(no default streams) negates one of the whole intended advantages of the
entire thing.
What am I missing?
Upgrades can never work without changing fundamental properties of modules.
There are two traits of modules that break everything:
* Module activation is introduces a hard lock of content source
* There is no concept of module transitions
In the RHEL world, these two qualities are not great, but they are
serviceable (RHEL 9 is going to hurt!). In the Fedora world, they make
having default modules essentially untenable. It could even be argued
that non-default modules are not serviceable either.
There is no way in modularity to say that a module is being replaced
with another. There's also no way to say that a module is going away
and transition accordingly. Moreover, since modules have a strong
dependency on an abstract property that is defined as a consequence of
the system content (the "platform" module), it is not possible to have
orphan modules that are still binary compatible as you upgrade.
Finally, modularization and foregoing non-modular versions of content
has an implicit commitment that you *never* demodularize because there
is no module transition capabilities in the modularity technology.
These flaws boil down to Fedora Modularity being a failure because the
technology does not account for the needs of Fedora as a distribution,
as a project, or as a community.
--
真実はいつも一つ!/ Always, there's only one truth!