On Sat, Jun 20, 2020 at 7:40 PM Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
On Thu, Jun 18, 2020 at 8:45 AM Josh Boyer <jwboyer(a)redhat.com> wrote:
Modularity has been an interesting idea on paper, but not worth the
effort. It should not be used for RHEL 9.
This is the wrong place to try to convince Red Hat otherwise. It's
also not going to happen. And frankly, I wouldn't want to.
> It is always good to push the boundaries and search for better
> and improvements, and that is part of what makes Fedora great. We are
> doing this in the context of the RHEL 9 release as well, so our near
> term timeline and requirements mean we are working on evolving
> modularity, not a revolution or a replacement. We are excited by ELN,
Or: you could discard modularity for RHEL 9. My experience with recent
Fedora releases and RHEL 8 has been that it's been destabilizing to
active and to build environments, with no detectable benefit.
Can you, or can anyone else, cite a single issue it has helped with?
Especially one that was not better resolved with other existing
deployment tools, such as /etc/alternatives or version pinning?
Yes, actually. The Nodejs and PHP language stacks, as they are shipped
in RHEL/CentOS 8, are tremendously useful in the current form.
From my perspective, there are two major advantages:
* The language stacks are maintained and operate consistently. What I
mean by this is that each variant of the PHP and Nodejs language
stacks presents the same, consistent interface. I can build on those
interfaces with one version and trivially move forward to the next one
when I'm ready.
* The module stream locking feature is useful in that I can trust that
updates will flow freely for those modules, and I don't have to fiddle
with any fragile configuration in the package manager to keep things
going as I desire. It gives me the necessary control to shift at *my*
pace while still trusting that the whole stack is supported.
Are there problems with it? Absolutely. It was a tremendous effort for
me to bring up modularity support in my internal infrastructure. But
once I got there, I was able to realize these benefits for my own
pipelines. There are still problems, and I've filed bug reports about
them and communicated to the various developers about them, but it's
on a "trending upward" path for me.
And I won't lie and say I don't want improvements. I want to be able
to leverage it more. I want improved packager ergonomics. I want
content reusability (builds across multiple modules to be reusable for
modular content instead of building for each module if the
configuration is effectively the same). And so on.
But I will *not* argue to drop it in RHEL (or even Fedora) because I
think it is useful in a lot of ways and has potential to really make
our lives better.
真実はいつも一つ！/ Always, there's only one truth!