Once upon a time, Stephen John Smoogen <smooge@xxxxxxxxx> said: > 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. Thanks for the explanation - I agree with you, that if RHEL doesn't already have a base module (like the perl example you listed), then any EPEL module that overrides a base RHEL package needs to also proved the module to get back to RHEL. I get the desire/need for modularity... it just seems so complicated. As a really small-time packager, modularity has been over my head (but the few packages I have don't need it, so I also haven't tried super hard). -- Chris Adams <linux@xxxxxxxxxxx> _______________________________________________ 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
