On Tue, 2019-10-15 at 11:35 -0400, Neal Gompa wrote: > 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. I think this is actually a very cogent summary of the major problems we're dealing with in modularity right now, but it's *also* needlessly negative. Inventing new stuff is hard. You rarely get it right the first time. Speaking personally here I think it was a big mistake to do this second version of Modularity as fast as we did and drop it into RHEL 8 before it had been in Fedora for two minutes, that was an unforced error; but even if we hadn't done that, I'm not surprised the second cut at Modularity isn't perfect. The second cut at RPM wasn't perfect either, that's why we're on 4.x not 2.x. :) What's happening right now is the process of us trying something out and finding out where the problems are. That's what happens when you invent new stuff, it's harder than just carrying on doing the old stuff. So: I'm on board with most of what you say here, but there's no need to say it means Modularity is "a failure". It means right now it's not entirely baked and we're realizing the concept needs extending and perhaps reworking a bit, just like we realized with the *first* cut at Modularity which we abandoned between a Beta release and a Final release. This is causing us to have to deal with some icky problems, but again, that's not *new*. We had to deal with some fairly icky problems when systemd showed up. We had to deal with some fairly icky problems when grub2 showed up. It's a process we've dealt with before. We know how to do it. We just need to hold our noses and fix the icky problems, and then sit down and think about the design issues that have become apparent in Modularity v2 through our actually implementing it and using it (which is what Fedora is for, remember!) and figure out how to address them in Modularity v3. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ 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
