On Fri, Jun 21, 2019, at 19:17, Nico Kadel-Garcia wrote:
On Fri, Jun 21, 2019 at 8:45 AM Brian Stinson brian@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@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.