1

There is a .spec file to build an rpm package for our software. In the %pre section of the .spec file there is a check if a previous major version of our software is installed. If yes, the installation is aborted with a nice error message. In the former RHEL versions everything did work fine.

In RHEL 6.7 (and seems like also in RHEL 6.5) the rpm installer does not reach (or ignore?) the %pre section and complains that "file ... from install of our-software-server-23.01-1.el6.i386 conflicts with file from package our-software-server-22.07-1.el6.i386" and then the installation aborts. And there are tons of such files. And this is exactly the case that our %pre section in the .spec file was taking care about.

What has been changed in the rpm handling between the recent releases? I found nothing so far.

rpm --version shows 4.8.0

Any help is much appreciated!

%pre server
if [ $1 -gt 1 ]; then
# Check for an unsupported major version upgrade
INSTALLED_VER=$(rpm -q our-software-server|sed -e 's/our-software-server-\([0-9]\+\).*/\1/')
echo "Upgrade check:"
echo "installed  : $INSTALLED_VER"
echo "new version: %{majorver}"
if [ "$INSTALLED_VER" -ne "%{majorver}" ]; then
    echo
    echo "ERROR:"
    echo "An automatic RPM upgrade across major versions is not supported!"
    echo "Please refer to the Upgrade Notes on how to manually perform"
    echo "an upgrade and migrate the configuration data."
    echo
    exit 1
fi
...
2
  • 1
    this %pre section is for a sub-package named -server (our-software-server) ? -- just clarifying whether that's the actual conflict, given the general name in the question of "our-software" (which didn't specify our-software-server)
    – Jeff Schaller ♦
    Jan 12, 2016 at 21:05
  • Yes, you are right. I modified the question to reflect it.
    – Dime
    Jan 13, 2016 at 7:45

1 Answer 1

Reset to default
2

rpm-4.8.0 has added a global file lock in /var/lib/rpm/.rpm.lock that prevents an rpm install from recursing by invoking rpm in %post.

See why can't I install packages with rpm? I get "transaction lock"

Meanwhile there is very little need to have/use a global interprocess lock: rpm (and processes that depend on rpmlib like yum) hardly ever contend for a global lock.

Short answer: Rename the lock file before attempting rpm -q in %post, and restore the file before exiting %post. The lock race window opened by renaming the global lock file is vanishingly small in practice.

Note that using dependencies, rather than invoking rpm in %pre, is a far better solution than what you are attempting.

2
  • There was actually a misunderstanding from our side on how the rpm works. We did upgrade over a minor versions using the --install (-i) option. Our final solution is to add Conflicts: our-software-server, so it is no longer possible to do rpm -i if any version of our server software is installed and keep the current %pre section. Then the check in the %pre section will be executed if rpm --upgrade(-U) is called which seems to be the right way of upgrading our software over the minor versions. Also many thanks to the rpm mailing list for helping to understand our real problem!
    – Dime
    Jan 14, 2016 at 8:34
  • 1
    Yes, rpm -U|--upgrade should be used in almost all cases (kernel being the major exception). It's unfortunate that the intuitive meanings of "install" and "upgrade" do not conform to the technical implementation. With --install, rpm NEVER erases or clobbers any content, but will have multiple copies of packages installed (which is usually not what you want).
    – Jeff Johnson
    Jan 16, 2016 at 4:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .