On Sat, Feb 15, 2020 at 07:15:55PM -0700, Ken Dreyer wrote: > On Thu, Feb 13, 2020 at 5:54 AM Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > > > > 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 from clashes. 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 repositories too. 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 usual one. 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. -- Petr
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
