+++ 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 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 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 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.
After a quick decade we came to the conclusion that adding something to the package itself is not the right thing to do. While packagers should be able to select whether packages are multilib or not, this is a basically a distribution/spin level of decision. So the build infrastructure should (and nowadays does) take care of this and handles what package goes where. This way the same packages can be used for different distribution channels with different decision on how to handle multilib. Closing.