On Tue, Feb 25, 2020 at 3:57 PM Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > > On Tue, Feb 18, 2020 at 04:06:32PM -0800, Kevin Fenzi wrote: > > Consider: > > > > 1. foo rpm that is in the RHEL baseos. It's not in any module. > > Can epel make a foo (non default) module that overrides it? > > This is safe from a technical perspective and should be fully endorsed by EPEL. > > 2. foo rpm that is in a RHEL default module. > > Can epel make a foo (non default) module that overrides it? > > > > 3. foo rpm that is in a RHEL non default module. > > Can epel make a foo (non default) module that overrides it? 2 and 3 are safe from a technical perspective with one major caveat: they can only be replaced by an alternate stream of *the same module*. This is because otherwise both RPMs will be visible to the package manager and the behavior is complicated. I'm actually not sure which way it will break; either both sets of RPMs will be visible to the transaction and you'll end up with the highest NEVRA, regardless of which one you intended to get; or both modules will suppress each other and neither of their RPMs will be available. I think it's the first case, but either way it should be avoided. This is also why we (Merlin and I) determined that the `epel-` prefix was a non-starter; this case makes that too risky. If we want to find a way to highlight where a stream is coming from to disambiguate EPEL streams from RHEL streams, I think we need to do some UX work on `dnf module list` to display the source repo for each available stream in a meaningful way. Lastly, I think Petr Pisar is pretty much spot-on with his explanation of the EPEL -> RHEL transition; we need to make sure that the V(ersion) field in the module stream's NSVCA is higher for the new RHEL version than it is in EPEL, similar to what we do with non-modular packages today. In that case, DNF will just select the RHEL version of the stream as an update to the EPEL version of the stream and things should work out fine. The "gotcha" is those cases where the EPEL maintainer doesn't know that a RHEL update is coming and inadvertently updates to a higher version than RHEL ends up delivering. As this case is basically identical to the non-modular RPM case, the same mitigation strategies should work (either drop the conflicting module contents from the repo or else release a higher version in RHEL as an errata). _______________________________________________ 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
