Alex Scheel wrote:
Special care needs to be taken to make sure we discuss what happens
when a _module maintainer_ wants to switch the module stream of one
of its dependencies, especially a dependency the user never
specifically selected a stream for. That should be an allowed and fully
supported use case.
This was the pki-core<->idm module fiasco that was never resolved by
DNF/Modularity.
I'd post the bug number but the bug isn't public.
So perhaps split this into:
1. How does a _user_ change module streams during upgrade?
2. How does the _maintainer_ change module streams of a dependent
module? (module a -dep-> module b -- change stream of b from 1 to 2)
IMO, without a resolution in Fedora we'll never get one in RHEL.
Indeed, in Fedora, it is quite plausible for a package to be ported to a new
major version of a library in an update. (In RHEL, it actually also is, but
for different reasons, i.e., its extremely long lifetime.)
But this shows how modules are the wrong answer for non-leaf packages. What
happens if one of the packages you had installed wants to bump the module
stream of its dependency and another one doesn't? Then suddenly, your system
cannot be updated anymore, because the packages that previously coexisted
just fine now irremediably conflict.
(In fact, this is just a particularly nasty special case of the more general
design flaw of Modularity that Stephen Gallagher has unfortunately forgotten
in his list in the original post, the version conflicts caused by versioned
dependencies without parallel installability. The special case is that the
conflicts can also be introduced on updates to previously non-conflicting
packages.)
Providing incompatible versions of non-leaf packages MUST be done in a
parallel-installable way. There is no other way out.
Kevin Kofler