On Tue, Feb 25, 2020 at 1:16 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > > 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. > I agree > > > 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. > I recently talked with the software support group (I think that's their new name) asking about this, and it is the first. If two modules are both enabled, even if one is default and the other not, and the same package is in both, dnf will pick the highest NEVRA. While I agree that we should be very careful with this, I do not believe it should be completely off the table. I believe it should be permissible with the EPEL Steering Council's blessing, but not otherwise. Case in point is libssh2. It was provided in the original RHEL 8.0 virt module, but not since then. It's causing all sorts of grief, especially when people are using both RHEL8 (where you see it) and CentOS8 (where do you don't). There is a bugzilla ticket in with the team, but it looks like it's going to take a while before a fix get's implemented. My proposal is to create a libssh2 module, with a higher NEVR than in that original RHEL8 module. > 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 _______________________________________________ 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
