On Fri, 14 Feb 2020 at 18:14, Chris Adams <linux(a)cmadams.net> wrote:
Once upon a time, Kevin Fenzi <kevin(a)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.