On 7/17/20 1:50 PM, Daniel Mach wrote: > > > 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. Yes, that's something I already accepted. The real question is how to do the change in f33 considering that f32 and f33 modules must be built from the same modulemd file. I only see the ability to disable module stream build for f33. And now I'm curious what would happen if I specify `platform: [-f33]` and publish new module build. Would that remove previously published metadata from rawhide? I guess the right answer is somewhere around servicelevels and `eol` specification. -- With best regards, Aleksei Bavshin _______________________________________________ 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
