Bug 1805260

*** Bug 1866948 has been marked as a duplicate of this bug. ***

(In reply to Troy Dawson from comment #0)
> RHEL keeps all it's old modules, at least thus far they have.
> The problem is when packages get removed from modules, and new modules are
> shipped, those old packages, are still available and install-able.
> Not only are they available, but as far as we can tell, there is no way to
> *not* be able to install them if your module is enabled.
> 
That's how RHEL is designed to work: It retains all historical package and
module builds. It's not any different from non-modular packages.

> The specific problem we have is libssh2.
> libssh2 was shipped in the original virt module (version: 820190226174025). 
> But then it was taken out, and hasn't been in any virt module since then.
> But, it doesn't seem to matter how old the module is, libssh2 still shows
> up.  Even on a brand new RHEL 8.1 install.

I confirm the package was removed from 8010020190916153839 virt:rhel module build.
And confirm that these libssh2 binary packages are available if virt:rhel stream
is not disabled:

# dnf repoquery libssh2
Last metadata expiration check: 0:10:21 ago on Wed 21 Jul 2021 12:39:06 PM CEST.
libssh2-0:1.8.0-7.module+el8+2833+c7d6d092.x86_64
libssh2-0:1.8.0-7.module+el8.0.0+3075+09be6b65.1.x86_64
libssh2-0:1.8.0-7.module+el8.0.0.z+3418+a72cf898.1.x86_64
libssh2-0:1.8.0-8.module+el8.0.0+4084+cceb9f44.1.x86_64

> As far as we can tell, there is
> no way to not have libssh2 show up on a RHEL8 machine.
> 
From user's point of view, the user can exclude the package in a DNF configuration
as with any other package. Add "exclude=libssh2" line to /etc/dnf/dnf.conf:

# tail -n 1 /etc/dnf/dnf.conf
exclude=libssh2

# dnf module list --enabled virt:rhel
Last metadata expiration check: 0:16:48 ago on Wed 21 Jul 2021 12:39:06 PM CEST.
Red Hat Enterprise Linux 8.5.0 AppStream - x86_64
Name                        Stream                             Profiles                         Summary                                    
virt                        rhel [d][e]                        common [d]                       Virtualization module                      

Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled

# dnf repoquery libssh2
Last metadata expiration check: 0:16:54 ago on Wed 21 Jul 2021 12:39:06 PM CEST.

But from a distributor point of, there is currently none. But we work on that. We augmented
modulemd-v2 format <https://github.com/fedora-modularity/libmodulemd/pull/566> which allows
module maintainers to delist a binary package from a module. Once this feature is merged
into RHEL libmodulemd (bug #1984402) and DNF (this bug report), module maintainers will be able to "remove" a package from
a module. The modular build of the package will be kept in the repository because
of historical builds, but it become unavailable to the package manager.

> Now, let's talk about CentOS8.  CentOS8 only keeps the modules going
> back to the point release.  So, for CentOS 8.1, there is no libssh2,
> because they don't have that old module sitting around.
> 
> This is causing problems for communities like EPEL.
> 
That was CentOS 8 decision to make it different from RHEL 8.

> We need a way for our users to not use old releases of modules, without
> disabling that module.

Yes, another option would be adding an exclude-like option for module builds into DNF
which would allow users to ignore a select module build version. Nevertheless DNF thinks the best option is giving module maintainers a way of delisting the unwanted packages in a new module build.

> But from a distributor point of, there is currently none. But we work on
> that. We augmented
> modulemd-v2 format
> <https://github.com/fedora-modularity/libmodulemd/pull/566> which allows
> module maintainers to delist a binary package from a module. Once this
> feature is merged
> into RHEL libmodulemd (bug #1984402) and DNF (this bug report), module
> maintainers will be able to "remove" a package from
> a module. The modular build of the package will be kept in the repository
> because
> of historical builds, but it become unavailable to the package manager.
> 

If this does what it sounds like, I think this will be a good solution.

> > We need a way for our users to not use old releases of modules, without
> > disabling that module.
> 
> Yes, another option would be adding an exclude-like option for module builds
> into DNF
> which would allow users to ignore a select module build version.
> Nevertheless DNF thinks the best option is giving module maintainers a way
> of delisting the unwanted packages in a new module build.

I think having an exclude-like option for module builds would be a good idea, but I don't think it would solve the problem this bugzilla is about. A user would have to know that they need to exclude a particular module.
I think having module maintainers being able to delist unwanted packages is the way to go.

I create PR (https://github.com/rpm-software-management/libdnf/pull/1327) that modifies modular filtering according to demodularized modular data (See https://github.com/fedora-modularity/libmodulemd/blob/main/yaml_specs/modulemd_stream_v2.yaml). When demodularized rpms (names) are specified in the latest module version, then dnf will not hide nonmodular rpm with the same name or the provide.

Link correction:

CI Tests: https://github.com/rpm-software-management/ci-dnf-stack/pull/1031

I am really sorry but we cannot enable demodularization in RHEL8 because it will brake ubgrade path from 8.0 gold image without requirement of dnf in the first step. The feature will be delivered in RHEL 9.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days