On Mon, Feb 17, 2020 at 1:00 PM Brian Stinson <brian at bstinson.com> wrote: > > 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/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 > > > > _______________________________________________ > > CentOS-devel mailing list > > CentOS-devel at 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 In the longer term, can we discard modules? Or encourage RHEL upstream to phase them out? I've not seen any reports of people actually using them successfully, only reports of their breaking dependency chains and causing obscure version conflicts when using the "--best" option for mock or dnf package selection.