Dne 17. 07. 20 v 14:15 Aleksei Bavshin napsal(a):
On 7/17/20 3:27 AM, Daniel Mach wrote:
Dne 17. 07. 20 v 11:04 Miro Hrončok napsal(a):
If the package was part of the module during the release of Fedora 32,
dnf will see 2 versions/builds of the module-stream:
- the one that existed during the release (containing the package)
- the one from updates (no longer containing the package)
The "original" version will still filter out the non-modular version
of the package from any transaction.
And given the way modular filtering works, a package cannot
technically be "demodularized" this was during one release, unless you
force a module reset from another package's scriptlet.
Thanks for clarifying this, Miro. So the filter is built based on the
module metadata instead of the installed packages. I guess I
misunderstood that part.
That's just sad. I woke up with the bright idea about removing the
packages from modulemd and then adding `sway-module-obsoletes` which
Obsoletes everything in the module that's behind f32-updates. We have
several packages like this since the last module rebuild.
If there's a cached non-updateable module metadata from fedora-modular
which is always considered by dnf together with the updated version from
fedora-updates-modular, that had no chance of working.
That's exactly how it works.
Unlike RPMs where usually the latest version is the result of a
transaction, module metadata are additive.
Sum of all versions make a stream and it's content (incl. the old RPM
versions) so you can eventually downgrade your package if you need to.
We know about the issue and we want to introduce some de-modularization
feature, but we need to fix more serious issues first.
During the update to Fedora 33 a modular reset should happen anyway.
But even if it doesn't I believe that the packages would be upgraded
to non-modular, assuming their EVR is higher. I might be wrong thou,
because the concept of removing packages from modules and making them
non-modular is full of booby traps.
The module reset is essential, because otherwise DNF will keep using
fail-safe module data on disk and that would still keep the package
filtered.
I suggest making the change in F33 / Rawhide.
Rawhide shouldn't break, because there's only one (the latest) version
of each module in the repodata and if you release a new modulemd without
the package, everything should work as expected.
Your suggestion implies that there's a way to build different set of
packages for different releases within the same module stream, right?
Because with what Miro said, we are stuck with the requirement to update
every package we have in the module until f32 is EOL. I can't just drop
package x from modulemd and say "x won't be ever updated in f32 because
modularity" :(
The F33 change I suggested doesn't retrospectively apply on F32.
You're really stuck maintaining the package until F32 EOL.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/devel@xxxxxxxxxxxxxxxxxxxxxxx
