[CentOS-devel] A Big Idea for a New Decade [was: Minutes for CentOS Board of Directors 2019-12-18 Meeting]

Neal Gompa

ngompa13 at gmail.com
Fri Jan 10 02:42:49 UTC 2020

On Thu, Jan 9, 2020 at 8:54 PM Nico Kadel-Garcia <nkadel at gmail.com> wrote:
> On Thu, Jan 9, 2020 at 10:55 AM Matthew Miller <mattdm at mattdm.org> wrote:
> >
> > On Wed, Jan 08, 2020 at 06:35:13AM -0500, Kaleb Keithley wrote:
> > > How is that different than just building them in EPEL and being done with
> > > it.
> > >
> > > Has something changed in the EPEL rules that would now allow us to ship
> > > packages that conflict with the packages in base RHEL or a RHEL product
> > > like RHGS (GlusterFS) or RHCS (Ceph)?
> >
> > Yes -- this should be possible with modularity. You'd ship the conflicting
> > packages as an alternate stream. No default streams allowed, but people could
> > opt in. And presumably there could exist media where that stream is enabled
> > by default.
> Since modularity has been pretty firmly proven not to work, both for
> RHEL 8 and in Fedora, why would you even consider  relying on it. It's
> already preven a destabilizing influence in RHEL and CentOS 8 and
> pretty much discarded for Fedora 32. The current chafing example in
> RHEL  8 and CentPS 8 is Perl dependencies, but they keep happening.
> I've not yet seen any hint that they will be any significant part of
> Fedora 32.

Modularity as a concept has not been "firmly proven not to work".
There *are* issues in the current implementation, and I *do* have
concerns about the state of affairs as it stands, but it's not over
yet! It mostly works fine in RHEL/CentOS 8, even if it is a pain in
the neck to build stuff on top of. There's no indication that
Modularity is going away for Fedora 32. Indeed, I'm pretty sure there
will be significant work going on in the background to make it better.

真実はいつも一つ!/ Always, there's only one truth!

More information about the CentOS-devel mailing list