Re: Proposed official change to EPEL guidelines: modules and RHEL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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

_______________________________________________
epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx

[Index of Archives]     [Fedora Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Announce]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Linux Apps]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux