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