[EPEL-devel] Re: Need to get Steering Committee consensus: packages in old modules
On Tue, Feb 4, 2020 at 12:37 AM Petr Pisar wrote: > > 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 So, I just want to bring up something. The customers assumptions were wrong. 1 - They said that libssh2 was in RHEL 8.0 AppStream, but removed in RHEL 8.1. Nope, it was never in a non-module in RHEL 8 at all. 2 - They said that libssh2 is not available at all in RHEL 8.1, even from modules. Nope. It totally is. I just did a fresh install of RHEL 8.1. This is a minimal install, but even minimal get's the virt module enabled. The RHEL 8.1 module has libssh2 in it. The rumor that libssh2 was in RHEL 8.0 AppStream is false. The rumor that it was removed in RHEL 8.1 is false. BUT ... that doesn't change the problem that people want libssh2 from EPEL. I think this is a valid request and should be discussed. I just want the facts to get straightened out. Troy ___ 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
[EPEL-devel] Re: Need to get Steering Committee consensus: packages in old modules
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 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
[EPEL-devel] Re: Need to get Steering Committee consensus: packages in old modules
On Mon, Feb 3, 2020 at 5:33 PM Kevin Fenzi wrote: > > On Mon, Feb 03, 2020 at 02:15:19PM -0800, Troy Dawson wrote: > > On Mon, Feb 3, 2020 at 12:29 PM Neal Gompa wrote: > > > > > > On Mon, Feb 3, 2020 at 2:36 PM 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? > > > > > > > > > > Since libssh2 is being dropped from RHEL, I think we should just > > > permit it as a regular package in EPEL proper. That maximizes its > > > usefulness to everyone. > > > > > > > I second that. > > I don't think it matters if it was in a module or not. If it is no > > longer in RHEL8, then it should be permitted as a regular EPEL8 > > package. > > I agree, but... what about packages that are modules. > > What does epel promise not to overlap with? Just bare rpms? > Any rpm in any modules also? > > ie, would it have been ok to make a normal rpm of libssh2 before when it > was in a module? > My understanding is that the only main contract we're maintaining is with bare RPMs. So technically, yes, it would have been okay to do so before when it was in a module because we can't use that anyway without pulling in the module as a dependency anyway, and for a lot of reasons, it's probably a good idea to avoid that whenever possible to maintain flexibility for downstream consumers. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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
[EPEL-devel] Re: Need to get Steering Committee consensus: packages in old modules
On Mon, Feb 03, 2020 at 02:15:19PM -0800, Troy Dawson wrote: > On Mon, Feb 3, 2020 at 12:29 PM Neal Gompa wrote: > > > > On Mon, Feb 3, 2020 at 2:36 PM 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? > > > > > > > Since libssh2 is being dropped from RHEL, I think we should just > > permit it as a regular package in EPEL proper. That maximizes its > > usefulness to everyone. > > > > I second that. > I don't think it matters if it was in a module or not. If it is no > longer in RHEL8, then it should be permitted as a regular EPEL8 > package. I agree, but... what about packages that are modules. What does epel promise not to overlap with? Just bare rpms? Any rpm in any modules also? ie, would it have been ok to make a normal rpm of libssh2 before when it was in a module? kevin 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
[EPEL-devel] Re: Need to get Steering Committee consensus: packages in old modules
On Mon, Feb 3, 2020 at 12:29 PM Neal Gompa wrote: > > On Mon, Feb 3, 2020 at 2:36 PM 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? > > > > Since libssh2 is being dropped from RHEL, I think we should just > permit it as a regular package in EPEL proper. That maximizes its > usefulness to everyone. > I second that. I don't think it matters if it was in a module or not. If it is no longer in RHEL8, then it should be permitted as a regular EPEL8 package. Troy ___ 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
[EPEL-devel] Re: Need to get Steering Committee consensus: packages in old modules
On Mon, Feb 3, 2020 at 2:36 PM 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? > Since libssh2 is being dropped from RHEL, I think we should just permit it as a regular package in EPEL proper. That maximizes its usefulness to everyone. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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
