[SOLVED] How to prevent an RPM from being treated as a multilib package

Issue

Changing a binary (.so) in an RPM package from 32bit to 64bit seems to result in rpm treating it as a multilib package. The consequence is that the old version of the package is not uninstalled when the new version is installed using "rpm -U". This is a problem for us because the files from the old version must be removed during the rpm upgrade. Manually uninstalling the old version is not an option.

Is there any configuration we can use in the rpm spec file to prevent the rpm from being treated as a multilib package? We use CentOS 7.

One thing we tried is the "Obsoletes" tag in the rpm spec file but this did not result in uninstalling the old version.

Solution

E.g. on my system I have these two multilib packages:

$ rpm -q --provides libpcap-1.7.3-1.fc22.i686
libpcap = 14:1.7.3-1.fc22
libpcap(x86-32) = 14:1.7.3-1.fc22
libpcap.so.1
$ rpm -q --provides libpcap
libpcap = 14:1.7.3-1.fc22
libpcap(x86-32) = 14:1.7.3-1.fc22
libpcap.so.1
libpcap = 14:1.7.3-1.fc22
libpcap(x86-64) = 14:1.7.3-1.fc22
libpcap.so.1()(64bit)

My system is 64bits. So when I use:

Obsolete: libpcap

The rpm will just try to obsolete the 64bits version. You have to use:

Obsolete: libpcap(x86-32)

Which should replace that 32 bit version. So just query your old package if it provides something with (x86-32) and then obsolete that one provides. In case there is no such provides, you have do that in two steps:

1. rebuild your old package, bump release, put there manually

   Provides: somethig_just_for_upgrade(x86-32)

   Then put this package in your repo, so you customer will upgrade to this one.

2. Put in your 64bits package:

   Obsoletes: somethig_just_for_upgrade(x86-32) <= 1.0.0

   So in next upgrade customers will upgrade to that 64 bits version.

Answered By - msuchy

Answer Checked By - Robin (WPSolving Admin)