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@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org

Reply via email to