On Fri, 14 Feb 2020 at 18:14, Chris Adams <linux@cmadams.net> wrote:
Once upon a time, Kevin Fenzi <kevin@scrye.com> said:
> Does this mean if there's a package foo that is a rhel package, but not
> in a module, that it can be overlapped with a foo package thats in a
> epel non default module? ie, does it only mean the modular case or does
> it mean any rpm?

As a consumer of EPEL, I'd rather nothing in the base RHEL (or really
CentOS in my case) ever get replaced, up or downgrade, by something in
EPEL.

Unless... does RHEL have modules that replace base packages?  I admit, I
haven't fully got my head wrapped around all the effects of modularity.


So the way that RHEL did this in el8.0 seems to have been to make a pseudo module

perl   5.24          common [d], minimal   Practical Extraction and Report Language                          
perl   5.26 [d]     common [d], minimal   Practical Extraction and Report Language                          

The perl-5.24 is a real module built in the modularity system. If you do a yum module info perl, it gives you every package in it. The perl-5.26 module is a 'stub' where it mentions mainly masks in the base packages like perl-interpreter-5.26.3-416.el8.x86_64 . So you can replace all the core perl packages with a module.. 

From my also little understanding of modularity, this is so you can reinstall base perl packages. In some ways ( I am glossing over things here), modular rpms always beat bare rpms because a module can put in rules to say 'you can install this package but it does not work with these rpms so they need to be removed'. So I think any modules we write which would over-ride non-modular packages, we would also need to write a 'get me back my f'ing defaults' module which stubs in a similar way the perl and some other modules do. 


--
Stephen J Smoogen.