On Wed, Jun 24, 2020 at 12:48:07PM +0200, Daniel Mach wrote:
> My idea was that DNF could discriminate the same-name package
> ModularityLabel tag instead of relying on modulemd documents delivered in the
> repository metadata.
The "modularitylabel" is not going to help.
It's designed as a boolean flag.
If it holds any value, it indicates that the RPM is part of a module.
If it's empty, then the RPM is non-modular.
If you're looking for any sense of the header, it's probably closest to a
reference to the module build it comes from.
RPMs are supposed to be re-used among modules/contexts and for that reason
we cannot hardcode this relation directly to them.
I know all this things, but:
ModularityLabel tag can be interpreted not only as a boolean. It was added to
recognize a modular package for a case when a repository with modulemd
metadata disappears. This is where the interpretatinon as a boolean type comes
from. But here we discuss a new modularity that does not have to align to the
current implementation of modularity.
The ModularityLabel tag carry name:stream:version:context of a module build
where the RPM package was built. I know that a package can be reused in a new
module version and then the ModularityLabel won't match exactly. But that's
not a problem, because nobody cares about a version of the module. E.g.
current DNF implementation puts all modular packages from a single
name:stream:context onto one heap. The version is ignored. The same would
apply to the ModularityLabel tag.
Referring to modulemd data that are not available on RPM level when this
mental excercise is about blending modularity into RPM level defies the