On Tue, Feb 25, 2020 at 1:16 PM Stephen Gallagher <sgallagh(a)redhat.com> wrote:
On Tue, Feb 25, 2020 at 3:57 PM Matthew Miller <mattdm(a)fedoraproject.org> 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(a)lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproj...