A note for @mohanboddu , @kevin or whoever gets to commit the change - the change is needed just in Rawhide/Branched in this case. Thank you.

I quickly looked at rdma-core packaging and I'm wondering if it really needs to be multilib? It doesn't ship anything at all under /usr/lib64 so even if it is shipped as multilib, its contents is going to exactly match between i686 and x86_64.

I understand the reason for filing this ticket is that people updating from F32 and F33 are running into a multilib issue due to a dependency chain where rdma-core was pulled in as a library dependency. This is of course a real issue, but I wonder if there's maybe a different way to solve it?

Maybe rdma-core self-obsoletes would be enough to get rid of the installed multilib version when doing updates so it doesn't need to be in the multilib whitelist?

Hey Kalev. The F32/F33 issue was resolved by @honli reverting the packaging changes:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-b6cae5ac96
https://bodhi.fedoraproject.org/updates/FEDORA-2021-987b06d6fe

So we only care about Rawhide now. I specifically noted in bugzilla that I don't know whether rdma-core needs to be multilib, I hoped @honli would know. But if you think it doesn't, what is the proper way how to end multilib for a package when people start upgrading to F34? I couldn't find any packaging guide documentation for it. Can you add Obsoletes to the spec file which would only apply for the x86_64 package and it would only obsolete the i686 package?

Btw, I see that rdma-core contains /usr/sbin/rdma-ndd. Can the binary be a reason to ship this as multilib?

Hey Kamil,

I totally agree that it's best to do these kinds of changes in Rawhide only to avoid accidentally breaking people's F32/F33 systems. Good call on reverting the packaging changes there.

As for /usr/sbin/rdma-ndd, I don't think it should be a reason for the package to be multilib. When a multilib package ships a binary under /usr/sbin or /usr/bin, rpmbuild marks the files there with a certain "file color" (see rpm -q --filecolor rdma-core | grep bin) which makes it so that when both the i686 and x86_64 version of the rpm are installed, only the x86_64 version of the binary (/usr/sbin/rdma-ndd) is actually on the disk. This is how we do multilib in Fedora: there's parallel installation of libraries under lib/lib64, but for binaries, only the x86_64 version is actually installed on the disk.

My understanding of the issue here is that rdma-core was historically multilib because the way it was packaged (various library packages had an archful dep on the rdma-core package), not because anyone actually needed rdma-core to be multilib.

So to me it would make sense to instead try to make it so that rdma-core stops being multilib :)

I would suggest trying to add

# Self-obsoletes to remove unneeded multilib version on upgrades
# This is safe to remove in Fedora 36 but is needed in older versions in order to support F33->F35 upgrades.
Obsoletes: %{name} < %{version}-%{release}

to the rdma-core package main section and putting that to rawhide and then once it makes it to composes, do a distro upgrade test from F33 (dnf install rdma-core.i686 rdma-core.x86_64) and see if the i686 version gets correctly removed when updating to rawhide.

My understanding of the issue here is that rdma-core was historically multilib because the way it was packaged (various library packages had an archful dep on the rdma-core package), not because anyone actually needed rdma-core to be multilib.

I think you are right. I have no idea why rdma-core was being multilib.

I opened ticket issue to avoid regression issue for Fedora Rawhide (F34) multilib users.

So to me it would make sense to instead try to make it so that rdma-core stops being multilib :)

Let's try to stop it being multilib for Fedora rawhide. If it is really has to be multilib, we can revert what we changed for Fedora rawhide.

I put my suggestion to https://src.fedoraproject.org/rpms/rdma-core/pull-request/7 if you want to review and merge.

Thanks, Kalev. @honli , can you please close this ticket, so that releng folks know that we no longer want it in the multilib whitelist? We can continue the discussion in the PR, if needed.

Thanks all for your help.