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!