On Tue, Oct 15, 2019 at 12:27 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > 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. RHEL isn't holding Fedora hostage. That's also unnecessarily antagonistic. I think treating Fedora and RHEL as entirely separate things, and not part of the same ecosystem is exactly what got us into this in the first place. Red Hat is trying to address this because we very much see how the disconnects happen, and how they are problematic for everyone involved. There is pain felt on the enterprise side as well. If we take a step back and consider all of the various pieces of our ecosystem, it makes sense to try and figure out ways to make them as cohesive as possible. Not the same, but not wildly and problematically different either. Fedora, RHEL, and now CentOS Stream are all pieces of that. What you call "holding hostage" I would call an attempt to proactively contribute in the various communities we are all a part of. There has been reluctance to do that in the past and it has cost both sides. It will be messy and there will be growing pains. I would ask that we have patience and assume positive intent. It is fine to raise technical concerns, but they don't need to be portrayed in a manner that makes it seem like the communities are in direct conflict. josh > 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 _______________________________________________ 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
