Need to get Steering Committee consensus: packages in old modules

[Stephen John Smoogen]

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?

-- 
Stephen J Smoogen.

[Neal Gompa]

On Mon, Feb 3, 2020 at 2:36 PM Stephen John Smoogen <smooge(a)gmail.com&gt; 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!

[Troy Dawson]

On Mon, Feb 3, 2020 at 12:29 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  On Mon, Feb 3, 2020 at 2:36 PM Stephen John Smoogen <smooge(a)gmail.com&gt; 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

[Kevin Fenzi]

On Mon, Feb 03, 2020 at 02:15:19PM -0800, Troy Dawson wrote:
>  On Mon, Feb 3, 2020 at 12:29 PM Neal Gompa <ngompa13(a)gmail.com&gt;
> wrote:
>  >
>  > On Mon, Feb 3, 2020 at 2:36 PM Stephen John Smoogen <smooge(a)gmail.com&gt; 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

[Neal Gompa]

On Mon, Feb 3, 2020 at 5:33 PM Kevin Fenzi <kevin(a)scrye.com&gt; 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 <ngompa13(a)gmail.com&gt; wrote:
>  > >
>  > > On Mon, Feb 3, 2020 at 2:36 PM Stephen John Smoogen <smooge(a)gmail.com&gt;
> 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!

[Petr Pisar]

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

[Troy Dawson]

On Tue, Feb 4, 2020 at 12:37 AM Petr Pisar <ppisar(a)redhat.com&gt; 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