On Tue, Oct 15, 2019 at 12:52 PM Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > > 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. > The hostage situation predates all this new stuff. Perhaps now it's not a hostage situation, but it definitely felt like it leading up to RHEL 8's release. I felt like we were railroaded into the design that we have today, and aside from some minor late-stage adjustments, we felt really out of the loop for its actual development. -- 真実はいつも一つ！/ 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
