RPM Support

If a module stream is marked as a module default, then nonmodular RPMs are allowed to depend on it. [0]

Not only are they allowed to depend on it, but any version provided by a default module is to be preferred over a nonmodular package if one exists. Even if that nonmodular package has a higher version. [0]

That is to say that if a repo contains a nonmodular RPM that provides foo version 1.8 and also a default module whose artifacts provide foo version 1.5, DNF and other clients will always pick the module. [1]

So default modules are "special", but their specialness comes from a logically separate piece of metadata that Pulp stores separately.

We need to make sure the depsolver does 2 things:

• During depsolving, all default modules must be considered and preferred if available
• If a default module is ever copied, we must also copy it's module-default metadata

The second point is critical. If we copy the module without copying the module-default metadata, clients will not understand that it is special, and they will not be able to use them to satisfy their dependencies (the repo will be effectively broken), and the packages they provide will not be able to be installed normally through DNF as intended.

[0] As per discussion with Stephen Gallagher and Igor Gnatenko

[1] For instance, the "ninja-build" package is provided both by a nonmodular RPM in the fedora base repo and as a default module. If I try to install ninja-build, it will not install the nonmodular RPM, it will automatically enable the ninja module and install it from there. I've been told that the only reason it's provided as both is that they haven't updated the build tooling to allow modules in buildroot.