On ma, 17 helmi 2020, Paul Clifford wrote: >On 14/02/2020 14:28, Alexander Bokovoy wrote: >>I think both of these builds belong to idm:DL1, just to two different >>module builds. There are other packages from idm:DL1 module stream that >>are duplicated. >> >>Module build 253: https://koji.mbox.centos.org/koji/builds?tagID=488 >>Module build 265: https://koji.mbox.centos.org/koji/builds?tagID=513 > >As far as I can see the RPMs from older builds are kept in the CentOS >repositories but the associated module metadata isn't. > >For example, you can see both softhsm packages from the above builds in: >http://mirror.centos.org/centos-8/8/AppStream/x86_64/os/Packages/ > >But the "modules" file currently pointed to by repomd.xml only >contains metadata for build 265 (search for "stream: DL1"): >http://mirror.centos.org/centos-8/8/AppStream/x86_64/os/repodata/15776f65b6612ee4b6acbc9f7b9981e88198a0b97b01a4ce98d7b0ab7ed28ccc-modules.yaml.gz > >I don't think there's any other way for dnf to tell that an RPM is >part of a module before downloading it, but currently each time a >module build is published it appears to push the previous version out >of the "modules" repository metadata. > >This leads to the current behaviour where disabling a module only >hides RPMs from the latest module build, and earlier versions "leak >out" into transactions, eg: > $ sudo dnf -y module disable go-toolset > ... > $ sudo dnf install golang > (incorrectly offers to install package from previous module build) Looks like a real issue to track in dnf/compositor code? -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland