On Sat, Feb 15, 2020 at 07:15:55PM -0700, Ken Dreyer wrote:
On Thu, Feb 13, 2020 at 5:54 AM Matthew Miller
> In EPEL 8 or later, it is permitted to have module streams which contain
> packages with alternate versions to those provided in RHEL. These packages
> may be newer, built with different options, or even older to serve
> compatibility needs. These MUST NOT be the default stream -- in every
> case, explicit user action must be required to opt in to these versions.
Is there any chance that a module in EPEL 8 will be named identically
to a module in RHEL 8? If that happens, what is the process to choose
between RHEL's module and EPEL's module?
This is not entirely hypothetical :) We face this situation if we
consider putting Ceph into a module in RHEL 8 and a module in EPEL 8.
This was discussed in fall last year without any conclusion. There was
a proposal force all EPEL streams having a prefix (e.g "epel-") to prevent
In my opinion the situation with same named streams is similar to situation
with same named packages. If RHEL is going to add new package that already
exists in EPEL, RHEL uses an higher NEVRA of the package and EPEL will remove
the package later. You can do the same with module streams.
Module streams also have versions. The version is based on a RHEL version and
a time when the module was built. That itself ensures incrasing stream
versions. But that's not enough to ensure an upgrade path on package level.
The reason is that if a stream is enabled, all of its versions that exist in
the repositories are inspected and all of their packages are made available. That
means that if a RHEL repository contains multiple versions of a stream, then
DNF will see all the historical packages. That would apply to EPEL
A solution is that RHEL will ensurure that each package of the stream will
have an higher NEVRA than the EPEL one. See it's the same as with non-modular
packages. The only difference is that you need account more packages than the
The only remaining issue is what to do with packages that existed in EPEL
repository but were not added into RHEL repository. Well, technically it does
not matter that there is an old package.
When it would matter is when RHEL decided to add the package as non-modular
one and at the same time the RHEL stream would be a default one. Then DNF
would prefer the old modular package because the stream is default now. EPEL
could solve it by removing the old module from its repositories. But what if
the the user had already have the package from EPEL stream installed. In that
case, I believe, I'm not sure how exactly DNF implements it, DNF would kept
considering the package as modular because DNF cashes modular metadata of
installed packages for the case when a repository becomes unavailable.
A long term solution is DNF to support obsoleting modular packages by
non-modular packages or handling end-of-life streams better. As far as I know
this has not yet been designed, neither implemented.
So the bottom line is: Prefixed streams should provide a bullet proof
mitigation. Until DNF gains the ability to obsolete a stream, there will be
slight risk of creeping out-dated EPEL content into the installation.