[CentOS-devel] Packages dropping out of modules

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