On Mon, Feb 17, 2020, at 08:37, Alexander Bokovoy wrote:
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/15776f65b66...
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
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Thanks all for the reports. We're looking into how to distribute AppStream a little differently to resolve this.
--Brian