It is really tricky example and it requires deep discussion whether we can call it as a feature or bug. Dnf also shows content of not enabled or default module streams when they are a dependency of enabled or default module. It is the same principle, same strange principle but it is required for proper functionality of enabled module. What do you think?

(In reply to Jaroslav Mracek from comment #1)
> It is really tricky example and it requires deep discussion whether we can
> call it as a feature or bug.

I expect that if 

  module_stream_switch=true

then distrosync is performed on obsoleting a stream the same way as "dnf module switch-to" does.

> Dnf also shows content of not enabled or
> default module streams when they are a dependency of enabled or default
> module. It is the same principle, same strange principle but it is required
> for proper functionality of enabled module. What do you think?

I believe I had no other stream enabled. And Fedora has no default streams.

Then run `dnf distrosync --setopt=module_stream_switch=true`. Or system_upgrade will do it for you automatically. It is quite dangerous to use `module_stream_switch=true` as a permanent value on your system. It can trigger unwanted changes even when you trying to install one  package from different major version of your distribution. I guess that we can extend functionality of module-switch command but because all of that fun is already covered by system-upgrade it has very low priority or even it is a good candidate to be close in favor of other issues. What do you think?

I think that system-upgrade is not enough. What I want is a obsoleting module stream in a middle of a Fedora release life cycle. Hence a normal "dnf upgrade" should handle it.

Thanks I understand what you want to achieve but it will be a shock for users when `dnf` starts to downgrade packages during upgrade. Personally I do not recommend such a change for `dnf upgrade` command. Or I recommend to create from it a packaging issue. I am 100% sure that a packager can provide an upgrade path on RPM level. Please do not ask for any additional magic in DNF.

If this is a request for change of behavior of upgrade command that it starts to behave like distrosync or module-switch I would like to close it as wont fix.

What do you think?

I think you are overly conservative. Modules have independent life cycle from the distribution and DNF should respect it and strive for a smooth experience as much as possible. Modular obsoletes which recommends a replacing stream needs to be honored in "dnf upgrade". Otherwise you keep a user stuck on unsupported software. In my opinion considering stream switches as something exceptional which can happen only on dist-upgrade is ill by design and places a user to a dead-end.

If you don't want to implement the stream switching because it's too difficult or to innovative, then at least implement reporting the obsoletes in a DNF output so that a user can benefit from them (i.e. get notified about the EOL and manually switch to the recommended replacement).

I studied this particular perl:5.32 failure again.

perl:5.32 is missing perl-Pod-Parser package comparing to perl:5.30. That's not a packaging bug. perl-Pod-Parser was simply removed by the upstream from Perl 5.32. Though, it still exists separately from Perl, hence no RPM Obsolete: perl-Pod-Parser" is there. So you are right that perl:5.32 is not an RPM-wise superset of perl:5.30. Thus the "upgrade path on RPM level" was not held. When I uninstalled perl-Pod-Parser, then "dnf upgrade" with module_obsoletes=true and module_stream_switch=true passed.

Technically a packager should create a new perl-Pod-Parser module and extend the modular obsoletes to replace perl:5.30 with perl:5.32 and perl-Pod-Parser:SOMETHING. However modular obsoletes format does not support it yet. Nobody thought that modular obsoletance could be 1:N map. I will note this as an enhancment request for the modular format.

(In reply to Petr Pisar from comment #7)
> Technically a packager should create a new perl-Pod-Parser module and extend
> the modular obsoletes to replace perl:5.30 with perl:5.32 and
> perl-Pod-Parser:SOMETHING. However modular obsoletes format does not support
> it yet. Nobody thought that modular obsoletance could be 1:N map. I will
> note this as an enhancment request for the modular format.

https://github.com/fedora-modularity/libmodulemd/issues/598

Meanwhile, I will look whether adding "Obsoletes: perl-Pod-Parser < 0:1.63-441" into some of the perl:5.32 packages would help.

Adding "Obsoletes: perl-Pod-Parser < 0:1.63-441" into perl-libs of perl:5.32 indeed helps. But it's not a general fix:

(1) RPM-Obsoletes has 2 effects: Uninstalling the obsoleted package, and installing the obsoleting package. And the installation is a problem. If there is no always-installed package, like perl-libs in case of perl streams, adding Obsoletes into any package will be wrong because it will cause installing a unnecessary package. There is "Provides: libsolv-self-destruct-pkg()" hack, but I'm not sure how safe it. Does it need a dedicated package, or can it be placed in an installable package?

(2) Another problem is which version and release to RPM-obsolete. If another module delivering perl-Pod-Parser-0:1.63-440 will be added to the distribution, the RPM-Obsolete from perl:5.32 will interfere.

(3) Finally, the RPM-Obsolete is a hack because the obsoleting package has not relation to obsoleted package. It's similar misuse to a distribution-level fedora-obsolete-packages package. My gut feeling is that maintainer will be against spraying random packages with Obsoletes only to allow upgrading from a module to another module.

Because stream contents are generally incomparable, there is no upgrade path between them maintained. Therefore I'd rather see a distro-syncing module-switch on obsoleting modules.

Maybe a new "dnf module upgrade" subcommand could perform the distro-syncing module-switch.

(In reply to Petr Pisar from comment #10)
> Adding "Obsoletes: perl-Pod-Parser < 0:1.63-441" into perl-libs of perl:5.32
> indeed helps.

The (2) and (3) issues combined have a problem with third-party modules and packages. If somebody already has built perl-Pod-Parser for Perl 5.32 and it happened to be < 0:1.63-441, then adding the Obsolete will destroy his package.

E.g. When Fedora builds perl-App-cpanminus module, it builds perl-Pod-Parser as a build-only component a never distributes it. It could interfere with the Obsolete if it clashed on the release number of NEVRA. In this particular case there is no clash because the oldest supported perl-App-cpanminus:1.7044 builds perl-Pod-Parser-0:1.63-445. A similar case is when building perl:5.32 we also build a build-only perl-Pod-Parser-1.63-444. I think this illustrates why adding a seldom Obsoletes is a bad idea and it should rather be fixed by DNF with a distro-sync-like operation.


Jitka, do I have your permission to push this change into perl:5.32 (perl-libs subpackage of perl.spec in f34 branch)? I would condition the presence of the Obsolete with a build environment for perl:5.32 module:

%package libs
%if "%{_module_name}" == "perl" && "%{_module_stream}" == "5.32"
Obsoletes: perl-Pod-Parser < 0:1.63-441
%endif

I only add that perl:5.32 reaches EOL on 2022-06-01. Then the packagers won't be allowed to update that stream.

> Jitka, do I have your permission to push this change into perl:5.32
> (perl-libs subpackage of perl.spec in f34 branch)? I would condition the
> presence of the Obsolete with a build environment for perl:5.32 module:
> 
> %package libs
> %if "%{_module_name}" == "perl" && "%{_module_stream}" == "5.32"
> Obsoletes: perl-Pod-Parser < 0:1.63-441
> %endif

Yes, please add it.

(In reply to Jitka Plesnikova from comment #13)
> > Jitka, do I have your permission to push this change into perl:5.32
> > (perl-libs subpackage of perl.spec in f34 branch)? I would condition the
> > presence of the Obsolete with a build environment for perl:5.32 module:
> > 
> > %package libs
> > %if "%{_module_name}" == "perl" && "%{_module_stream}" == "5.32"
> > Obsoletes: perl-Pod-Parser < 0:1.63-441
> > %endif
> 
> Yes, please add it.

Fixed in perl:5.32:NN20220523110914.

I wanted to add a similar fix to perl:5.34 because after perl:5.32 EOL, DNF could upgrade directly from perl:5.30 to perl:5.34. But according to my test, DNF does not evaluate modular obsoletes transitively. Hence you need to do "dnf upgrade" twice to jump from perl:5.30 to perl:5.34. So the fix is not now required for perl:5.34.

(In reply to Petr Pisar from comment #6)
> I think you are overly conservative. Modules have independent life cycle
> from the distribution and DNF should respect it and strive for a smooth
> experience as much as possible. Modular obsoletes which recommends a
> replacing stream needs to be honored in "dnf upgrade". Otherwise you keep a
> user stuck on unsupported software. In my opinion considering stream
> switches as something exceptional which can happen only on dist-upgrade is
> ill by design and places a user to a dead-end.
> 
> If you don't want to implement the stream switching because it's too
> difficult or to innovative, then at least implement reporting the obsoletes
> in a DNF output so that a user can benefit from them (i.e. get notified
> about the EOL and manually switch to the recommended replacement).

Yes, but it is expected from us. Modules obsoletes is something like switching repositories. After switching repositories we have to work according rules baken in RPMs in the new repositories. Auto touching installed content was explicitly forbidden by several authorities and I agree with them.

I have no problem with implement automechanism that will provide the functionality, or reporting obsoletes. I only have a problem to do the RPM switch without explicit request from user.

Fine. I only can't understand you resistance in light of RPM Obsoletes which DNF handles without any questions.

I am sorry but with implementing requested feature we could create a problem with edge cases. I can figure some examples.

`dnf module enable` does not do the distrosync. And it is expected and it was required by modularity team representatives. The request was that changing rpm content must be triggered by user and not bu module enable command (not nice behavior but expected from users). User can enable module only to see the content or have a fun.

Enabling or disabling repository is also not triggering any changes on rpm content - no distrosync. Modules are virtual repositories with dependencies and conflict with other virtual repositories (modules) therefore they should behave by the same or similar way.

Another mess could be created when `module_obsoletes = True` and someone wants to install a package (not related to obsoleted module) from a different major version of distribution (rawhide) - it will not only switch module to the new stream but also it will replace module packages and not only installs requested package. This case is not easy to understand, but if anyone wants I can provide detailed information as an example.

I am sorry, this request sound very promising but in some cases it could be problematic. I strongly recommend to play with module obsoletes only between major distro versions and there is already system-upgrade which uses distrosync by default - therefore no issue.

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