Bug 653744 - Add tag(s) to allow packages to express non-multilib for compose
Summary: Add tag(s) to allow packages to express non-multilib for compose
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ---
Assignee: Florian Festi
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 650360
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-11-16 02:39 UTC by Bill Nottingham
Modified: 2023-11-23 15:23 UTC (History)
5 users (show)

Fixed In Version:
Clone Of: 650360
Environment:
Last Closed: 2023-11-23 15:23:16 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Bill Nottingham 2010-11-16 02:39:38 UTC
+++ 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.

Comment 1 Maciej Żenczykowski 2011-03-07 06:43:16 UTC
$ 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?

Comment 2 Panu Matilainen 2011-03-07 07:26:13 UTC
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.

Comment 3 Panu Matilainen 2011-05-26 11:54:56 UTC
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...

Comment 4 Fedora Admin XMLRPC Client 2012-04-13 23:13:36 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 5 Fedora Admin XMLRPC Client 2012-04-13 23:14:30 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 7 Pavel Raiskup 2017-01-10 11:25:32 UTC
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.

Comment 8 Florian Festi 2023-11-23 15:23:16 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.