[CentOS-devel] RFC: CentOS 8 Repository Structure

[Brian Stinson]

On Fri, Jun 21, 2019, at 19:17, Nico Kadel-Garcia wrote:
> On Fri, Jun 21, 2019 at 8:45 AM Brian Stinson <brian at bstinson.com> wrote:
> 
> > To be clear, the plan is to *not* ship separate repositories for ResilientStorage, NFV, HighAvailability, or RT. There may be components of those upstream channels that make it into BaseOS.
> 
> Given the python modules provided in those channels, they will
> definitely be needed in CentOS 8 or EPEL 8: I see python-boto3,
> python-botocore, and python-s3transfer, for example, in multiple RHEL
> 8 channels. Even if their segregation in multiple channels upstream
> was confusing or unwise, I'm not convinced it makes sense to try to
> merge them cleverly elsewhere in CentOS 8, especially if those
> channels ever differentiate when the individual modules are published
> upstream by RHEL. And since python modules *do* sometimes update,
> incompatibly with other python modules, I see a modest risk there.
> 
> Since "BaseOS" is its special little channel designed for the minimum
> core of highly stable, base system components like rpm itself, bind,
> and bzip2, I don't see how the frequently updated AWS published python
> modules would be appropriate there. Do you see a way such dynamically
> updated components would be appropriate there?
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel


It's not a question of modular/non-modular. There are quite a few non-modular RPMs shipped in AppStream, for example. It's more of a question of release and lifecycle bundles. 

Putting python-boto3, python-botocore, etc. (those are non-modular RPMs by the way) in BaseOS matches the expected lifecycle of those packages (although this is a wild guess on our part). AppStream might change within a traditional point-release, but the other upstream channels may not.