Bug 1686966

The issue could be easily solved by setting a Platform ID to platform:f30.

The important question is what should be a correct behaviour when dnf is unable to resolve correct context due to modular conflict or missing dependency.

Enabled or default module stream with conflict:
Current behaviour:
dnf excludes all modular packages from conflicting module and nonmodular packages are visible and installable.

What do you think is the best behaviour in this case?
I suggest that dnf must exclude all package from module. The important part is nonmodular packages that were excluded before a conflict appears.

Also important part is whatever we should make a difference between enabled modules and default modules?

(In reply to Jaroslav Mracek from comment #2)
> The important question is what should be a correct behaviour when dnf is
> unable to resolve correct context due to modular conflict or missing
> dependency.
> 
> Enabled or default module stream with conflict:
> Current behaviour:
> dnf excludes all modular packages from conflicting module and nonmodular
> packages are visible and installable.
> 
> What do you think is the best behaviour in this case?
> I suggest that dnf must exclude all package from module. The important part
> is nonmodular packages that were excluded before a conflict appears.
> 
> Also important part is whatever we should make a difference between enabled
> modules and default modules?

There still seems to be a difficulty with this --- If there are multiple contexts available and we can't select one, then how do we chose which module[s] to use for the purpose of name-based filtering of non-modular RPMs?

We need to resolve that; but generally, yes, I agree that even if the individual RPMs from the module here cannot be included because of context or dependency conflicts, we still need to use them for filtering and excluding non-modular RPMs.

[This also relates to another request, that we only use the *latest* module version for that name-based filtering; this would allow us to deliberately turn modular RPMs into non-modular ones by issuing an update that drops the RPM from the module but includes it as a non-modular package.  So in the case of dependency or context conflicts, maybe we use the latest module version from each possible context in the enabled stream?]

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

We need a design decision and discussion - see  Comment 3

I think there are two separate problems apparent here:

1. How to handle streams and contexts when we are updating to a new release
2. How to avoid updating to a non-modular RPM when the current stream+context is no longer valid (eg. because we are updating to a new release)

The first is about how to handle such rolling updates cleanly; that seems hard to do in general, and needs deeper discussion.

But the DNF modular fail-safe mechanisms can still help with #2.  We just need to make sure that even when the current repo modulemd cannot resolve a valid module stream+context given the current system configuration, we still keep locally-installed modular RPMs intact and avoid updating them to a non-modular RPM.

One of the DNF fail-safe mechanisms is to use a recent cached modulemd for any enabled module stream that does not have a valid modulemd in the repos themselves.  That seems like it would solve the immediate problem here.  We would need to make sure that the saved modulemd is not used for any decision-making purpose other than name-based filtering — we cannot use it for more than that as it is likely to have the same dependency and context problems as the modulemd in the repos.  

But as long as we have that copy for use in name-based filtering, then we will filter out any non-modular RPMs that might otherwise be incorrectly applied as an update.


That doesn't help us move to the right latest context when we do a major update; but it does at least stop us from updating to a clearly-incorrect non-modular RPM.

This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

The situation with modules was improved. We introduced static_context and new modular solver which make broken dependencies less problematic. The new solver also allows modular dependency changes. Also there is a plan to remove Platform Id from metadata == one source of problems will disappear. The platform is primary detected from metadata and then from OS release file therefore the issue will appear less frequently. We also have module obsoletes to help with upgrades.

As you can see so many things were delivered.

Because the problem reported here is related to Platform Id and DNF does not create it in metadata, and doesn't need it for anything I can close it or move it to distribution. Personally I feel that Platform ID should be removed from module dependencies therefore I am moving it to distribution.

Removing a run-time dependency on platform breaks building in MBS <https://pagure.io/fm-orchestrator/issue/1714>. MBS did it, and reverted back.
There is another possible approach: DNF will ignore the dependencies on platform.

This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '34'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07.

Fedora Linux 34 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release.

Thank you for reporting this bug and we are sorry it could not be fixed.

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