How to fix RPM conflict on package installation in rpmbuild spec file

Written by Claudio Kuenzler - 0 comments

Published on November 17th 2023 - Listed in Linux

The installation (or the upgrade) of a RPM package can fail with a conflict error when a specific path is already "in use" by another package.

Let's assume you have two packages:

foo => this is the "original" package serving a set of scripts, e.g. /opt/scripts/myscript.pl
bar => this is an alternative package, also serving a set of scripts, including /opt/scripts/myscript.pl

If the foo package is installed and you want to install the bar package (or upgrade bar package which contains an update with /opt/scripts/myscript.pl), the rpm command runs into a conflict:

[root@rhel9 ~]# rpm -Uvh bar-1.1.0-1.el9.noarch.rpm
Verifying...                          ################################# [100%]
Preparing...                          ################################# [100%]
        file /opt/scripts/myscript.pl from install of bar-1.1.0-1.el9.noarch.rpm conflicts with file from package foo-3.5.0.1-1.el9.noarch

Conflicts vs. Obsoletes

There are two ways to handle this situation when building the bar RPM package. In the bar.spec file you can:

Define the "foo" package as a package conflict under "Conflicts". This will make the bar package impossible to install as long as foo is installed.
Define the "foo" package as an obsolete package under "Obsoletes". This will remove the obsolete package "foo" when installing the "bar" package. From the documentation:

RPM removes all packages matching obsoletes of packages being installed, as it sees the obsoleting package as their updates.

Which one to chose heavily depends what purpose or what script versions both packages contain. You probably don't want to get on the nerves of the other package maintainer, so discuss this.

In my situation, the "foo" package has been abandoned for a while. It's just still in the repositories for legacy reasons. The scripts in the "bar" package replace the outdated scripts, including /opt/scripts/myscript.pl. Therefore, in my situation, defining the "foo" package under "Obsoletes" in the bar.spec file is the way to go.

Updating bar.spec

As mentioned above, I updated bar.spec and added the Obsoletes definition:

ck@mint ~/Git/packages/bar $ cat bar.spec
Name:       bar
Version:    1.1.1
Release:    1%{dist}
Summary:    bar package contains handy scripts
Packager:   Claudio Kuenzler, <ck@claudiokuenzler.com>
Vendor:     Infiniroot GmbH

Group:    Application/System
License:    GPLv3
Source0:    %{name}-%{version}.tar.gz
BuildArch: noarch

%if 0%{?rhel} == 6
Requires:    nc bind-utils perl
%endif
%if 0%{?rhel} == 7
Requires:    nmap-ncat bind-utils perl
%endif
%if 0%{?rhel} == 8
Requires:    nmap-ncat bind-utils perl
%endif
%if 0%{?rhel} == 9
Requires:    nmap-ncat bind-utils perl
%endif

Obsoletes:    foo

[...]

After building a new RPM package, it's time to test the new version.

RPM installation works, removes obsolete package

Now with a new bar package at hand, let's try the package installation/upgrade once more.

[root@rhel9 ~]# rpm -Uvh bar-1.1.1-1.el9.noarch.rpm
Verifying...                          ################################# [100%]
Preparing...                          ################################# [100%]
Updating / installing...
   1:bar-1.1.1-1.el9 ################################# [ 33%]
Cleaning up / removing...
   2:foo-3.5.0.1-1.el9 ################################# [ 67%]
   3:bar-1.0.99-1.el9 ################################# [100%]

The conflict is automatically resolved by removing the obsolete package "foo" and the package installation/upgrade of "bar" was successful.

Add a comment

Show form to leave a comment

Comments (newest first)

No comments yet.