Re: Removing packages from module

[Aleksei Bavshin]

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