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.