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. >> 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" :( -- With best regards, Aleksei Bavshin
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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
