On Wed, Jun 24, 2020 at 12:48:07PM +0200, Daniel Mach wrote: > > My idea was that DNF could discriminate the same-name package using the > > 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 purpose. -- Petr
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
