kalev added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/pungi-fedora/issue/981