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

Thu Jan 9 16:11:13 UTC 2020
Terry Bowling <tbowling at redhat.com>

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.
>
>
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200109/befbcb8d/attachment-0005.html>