On Sat, Feb 15, 2020 at 05:12:29PM -0500, Matthew Miller wrote:
> On Sat, Feb 15, 2020 at 11:27:46AM -0500, Stephen John Smoogen wrote:
> > From my also little understanding of modularity, this is so you can
> > reinstall base perl packages. In some ways ( I am glossing over things
> > here), modular rpms always beat bare rpms because a module can put in rules
> > to say 'you can install this package but it does not work with these rpms
> > so they need to be removed'. So I think any modules we write which would
> > over-ride non-modular packages, we would also need to write a 'get me back
> > my f'ing defaults' module which stubs in a similar way the perl and some
> > other modules do.
>
> No, this is not the case. If the module isn't enabled its packages will just
> be ignored. It's only if you enable the module that you get the RPMs from
> that module.
>
Exactly. If you want to revert back to a non-modular package, just reset the module
(e.g. "dnf module --reset perl"). That will disappear modular packages from
from the repository and make the non-modular packages available again.

Here is a simple explanation what enabling a module stream means: If you
enable a module stream ("dnf module --enable perl:5.24"), DNF obtains a list
of binary packages belonging to that stream (e.g. perl-interpreter-5.24.4),
makes them available (to dnf install, repoquery etc.) and at the same time
makes the same-named packages (either non-modular or from a different stream
of the same module) unavailable (e.g. perl-interpreter-5.26.3 disappears).
When you reset the module, you effectively reverts it. This process of making
the packages avaiable/unavailable DNF calles a modular filtering.

The purpose of the stub (without packages) perl:5.26 stream is different and
mostly unrelated . It is there to enable having modules above the perl module
in an easy way. Otherwise the layered module maintainers would have take care
whether they target Perl 5.26 that is non modular or Perl 5.24 that is
modular. The dummy perl:5.26 stream provides a unified modular interface to
other modules.

EPEL packagers that want to provide an alternative stream to non-modular
packages are not required to provide the dummy streams. Although the dummy
streams can become handy later for the very same reason. The dummy streams can
added later when needed and when found useful.

-- Petr
_______________________________________________
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave@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