On Mon, Feb 03, 2020 at 02:35:43PM -0500, Stephen John Smoogen wrote: > My main job is working with Fedora Infrastructure, and we are trying to > work out how to handle: > > https://pagure.io/fedora-infrastructure/issue/8558 > > The problem is that various tools filter what packages can be branched into > Fedora see that libssh2 was in a module that RHEL shipped in 8.0 but it is > no longer in the release with 8.1. > > Do we need to make libssh2 a module? > Should we allow libssh2 be branched as a 'bare' package in EPEL proper? > Other? > RHEL keeps old packages and old modules in repositories. That means even on a fresh RHEL 8.1 installation you will get a virt:rhel stream that will provide the libssh2 package. The package will come from an older virt:rhel module build. Because DNF prefers modular packages over bare packages, despite that EPEL provides libssh2 bare package, the EPEL one will be masked and the modular RHEL one preferred. Because virt:rhel is a default stream, the stream is active by default and thus this modular filter applies by default. Hence adding a bare libssh2 package to EPEL won't help. EPEL needs to provide a modular libssh2 package with a higher package NEVRA if the goal is to overtake the libssh2 package maintenance from RHEL to EPEL. So far my humble knowledge of DNF. I believe DNF team knows about this limitation and one of their goals for the future is to make a modular package obsolescence possible. -- 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
