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.
> It also doesn't solve being able to ship multiple versions in separate
> repos, e.g. gluster-5, gluster-6, and gluster-7. (I want to call those
> Streams, but I think Streams is used for something different.)
Streams is right, actually. As opposed to "CentOS Stream", singular.
I'll add a tiny bit of extra clarification here as this vocabulary is new to many people.
* RHEL Application Streams uses modularity to provide users multiple version options to meet their use case needs. For example, RHEL 8.1 provides PostgreSQL 9.6 and 10 (default version). These multiple application streams are made available from a single repository to provide easy access. Think of this as single repo with choices for different app versions, but a single Operating System distribution version.
* CentOS Stream is a distribution development stream of an entire OS that includes multiple repositories. So think of this more as the entire distribution, which just so happens to include a repository called appstreams providing the item above.
So based on what Matthew said, it sounds like changes to EPEL would allow it to provide a different set of "application streams" (enabled by modularity) of options for users to choose from and this repo could be used by both RHEL and CentOS.
I'm not sure if that helps or makes it more confusing, but I tried :-D
Thank you,
Terry Bowling
Sr. Product Manager - RHEL Automation & Management
Red Hat, Inc.