Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux