On Tue, Oct 15, 2019 at 11:22 AM Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> 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! _______________________________________________ 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
