Hide Forgot
+++ This bug was initially created as a clone of Bug #650360 +++ The i686 version of mesa-dri-drivers-experimental isn't uptodate. # yum list | egrep mesa-dri-drivers mesa-dri-drivers.i686 7.9-2.fc14 updates mesa-dri-drivers.x86_64 7.9-2.fc14 updates mesa-dri-drivers-experimental.i686 7.9-1.fc14 fedora mesa-dri-drivers-experimental.x86_64 7.9-2.fc14 updates Notice that experimental.i686 is at 7.9-1 while everything else 7.9-2. This breaks stuff. --- Additional comment from matt@mattmccutchen.net on 2010-11-13 21:58:12 EST --- Me too. I guess the multilib handling in mash messed up. I got the package from Koji: http://koji.fedoraproject.org/koji/buildinfo?buildID=202830 --- Additional comment from ajax@redhat.com on 2010-11-15 11:59:59 EST --- I sure do wish I knew a way to declare a package multilib. --- Additional comment from notting@redhat.com on 2010-11-15 21:36:41 EST --- Already fixed in 0.5.20, needs deploying. That being said, mash would be happy to honor a 'Multilib: yes/no' tag in RPM that was propagated into the metadata. None exists.
$ rpm -qa | egrep mesa-dri-drivers mesa-dri-drivers-7.9-5.fc14.x86_64 mesa-dri-drivers-experimental-7.9-5.fc14.i686 mesa-dri-drivers-experimental-7.9-5.fc14.x86_64 mesa-dri-drivers-7.9-5.fc14.i686 $ sudo yum list extras <doesn't list any of the above> Hence I would assume that this has been fixed?
The mash part is likely fixed, but this bug is about Bill's RFE to rpm: "That being said, mash would be happy to honor a 'Multilib: yes/no' tag in RPM that was propagated into the metadata. None exists." And that still doesn't exist, so lets leave this open.
Moving to rawhide to avoid timeouting + changing description so I dont have wonder what does mesa-dri-drivers-experimental have to do with rpm every time I look at bugzilla...
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
I was told that there might be requirement to do different multilib "decisions" per Fedora variant (Server/Cloud/...), maybe ?module? in future. But I'm curious why when we can also disable multilib for whole variant or module (in pungi/mash, regardless the multilib "boolean" in package). FWIW, I filed this https://pagure.io/pungi/issue/500 where we discussed something similar -> not a new RPM tag, but synthetic "Provides:". The consequence is that it would enlarge metadata in yum repos (though, IIUC, pungi analyses yum repository - not RPM). The pros is that we could implement this _immediately_, without waiting for RPM; only convenience macro and probably small fix in pungi would be needed. I'll interlink the reports so pungi guys can specify what would be needed to implement in RPM.