+++ 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 email@example.com 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:
--- Additional comment from firstname.lastname@example.org on 2010-11-15 11:59:59 EST ---
I sure do wish I knew a way to declare a package multilib.
--- Additional comment from email@example.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
$ 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
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.