On Tue, Oct 15, 2019 at 12:13 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > > 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. Are we going to do a Modularity v3? Because people seemed to be *really* reluctant to go down that path because it would break compatibility with RHEL. Honestly, my big problem is how much we're being held hostage by RHEL for this. I would have been happier if we'd focused on Fedora cases and naturally extended it to RHEL cases afterward. There's a very big difference between those examples and this one. I don't recall us being forced into a window to *ensure* it was in the sources from deriving into RHEL before. You are right that Fedora Modularity as a project is not necessarily a failure. But I stand by my consideration that the current implementation is a failure. From the build side to the user and developer UX, it's extremely painful and so far hasn't presented a lot of upside from a Fedora context. -- 真実はいつも一つ！/ 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
