Annoying, possibly dangerous rpm double install problem.

[Steven E. Protter]

Shalom and greetings,

Centos 5.4 64 bit.

One of my associates was playing around with installing an open source product called opensim, in spite of warnings that it should not be installed on a 64 bit system due to rpm conflicts.

Take a look at the results:
[root@mercury bin]# ./rpmfull.sh libpng
####output
libpng1.2.107.1.el5_3.2.x86_64 1261132407 (Fri 18 Dec 2009 04:33:27 AM CST)
libpng1.2.107.1.el5_3.2.i386 1261132501 (Fri 18 Dec 2009 04:35:01 AM CST)

### The rpm command
[root@mercury bin]# cat rpmfull.sh
rpm -q --queryformat '%{NAME}%{VERSION}%{RELEASE}.%{ARCH} %{installtime} (%{installtime:date})\n' $1

[root@mercury bin]# rpm -ql libpng-1.2.10-7.1.el5_3.2
/usr/lib64/libpng.so.3
/usr/lib64/libpng.so.3.10.0
/usr/lib64/libpng12.so.0
/usr/lib64/libpng12.so.0.10.0
/usr/share/doc/libpng-1.2.10
/usr/share/doc/libpng-1.2.10/CHANGES
/usr/share/doc/libpng-1.2.10/LICENSE
/usr/share/doc/libpng-1.2.10/README
/usr/share/doc/libpng-1.2.10/TODO
/usr/share/doc/libpng-1.2.10/example.c
/usr/share/doc/libpng-1.2.10/libpng.txt
/usr/share/man/man5/png.5.gz
/usr/lib/libpng.so.3
/usr/lib/libpng.so.3.10.0
/usr/lib/libpng12.so.0
/usr/lib/libpng12.so.0.10.0
/usr/share/doc/libpng-1.2.10
/usr/share/doc/libpng-1.2.10/CHANGES
/usr/share/doc/libpng-1.2.10/LICENSE
/usr/share/doc/libpng-1.2.10/README
/usr/share/doc/libpng-1.2.10/TODO
/usr/share/doc/libpng-1.2.10/example.c
/usr/share/doc/libpng-1.2.10/libpng.txt
/usr/share/man/man5/png.5.gz


Looks like the 64 bit version is there.

Now to actually compile opensim, which I don't really want done on my server I probably need to set the LD_LIBRARY_PATH variable to include the path to the 64 bit version of the libpng

I'm an RHCE, there are certain circumstances where having the i386 and the X86_64 version of the rpm is not a problem.

Just wondering if anyone has any experience on this. There are a number of rpm's involved and trying to remove libpng will pretty much destroy the system.

So questions:
1) Should I try and remove the 32 bit version of libpng and its mates?
2) If yes, how do I get rid of the 32 bit version, leaving the 64 bit version behind?

Regards,

SEP

[Matti_Kurkela · Accepted solution]

That's exactly how it should look when there's both the native x86_64 version and the 32-bit (i386) compatibility version of the library installed. Even the stock RHEL installer does this if you request it to install the 32-bit compatibility libraries.

Here's the output of your rpmfull.sh script in a rather minimal RHEL 5.5 installation which has *only* the packages installed from the stock RHEL 5.5 DVD image by the original Kickstart installation:

$./rpmfull.sh libpng
libpng1.2.107.1.el5_3.2.x86_64 1277307933 (Wed 23 Jun 2010 06:45:33 PM EEST)
libpng1.2.107.1.el5_3.2.i386 1277307933 (Wed 23 Jun 2010 06:45:33 PM EEST)

Our standard Kickstart installation includes the "32-bit compatibility libraries" group that is available in x86_64 installations.

Answers to questions:
1.)
If you wish, and really don't need the 32-bit libpng & co. packages on your system.

But keeping the libraries should not cause any problems, since the installation of the 32-bit library has probably happened "legitimately" during the original OS installation.

Look at the installation times: both the 64-bit and the 32-bit versions were installed in last December and only 2 minutes apart.

2.)
When you have two versions of a given RPM in a x86_64 system, add the architecture suffix to the RPM package spec. It should limit the operation to a single package only.

In other words, to list the contents of the 32-bit libpng only:

rpm -ql libpng-1.2.10-7.1.el5_3.2.i386

To remove only the 32-bit version, explicitly:

rpm -e libpng-1.2.10-7.1.el5_3.2.i386

If the rpm command turns out to be stupid and it removes the shared files too (/usr/share/doc/libpng-* and /usr/share/man/man5/png.5.gz), then force a re-installation of the 64-bit libpng package after that, and everything should straighten out:

rpm --replacefiles --replacepkgs -Uvh libpng1.2.107.1.el5_3.2.x86_64.rpm

The rpm command seems to have gained *some* intelligence for handling the dual-arch systems (i386/x86_64). Unfortunately I've seen it fail sometimes too.

--------------

A more careful removal plan, in case RPM gets very stubborn, or if you have to do this to something really important (like glibc):

- Backup the RPM database files, so you can easily return to status quo if the next operation does not work out

- List the files belonging to the troublesome package versions. Identify the files that are unique to the version you wish to remove (= not shared), and save that list into a file. You will be later using that list.

- Use "rpm --nodeps --dbonly -e " to make the RPM forget about the troublesome version

- Use "rpm --replacefiles --replacepkgs --dbonly -Uvh " to tell rpm that the "shared" files are now really controlled by the correct version of the package.

(Note: both rpm operations above will be restricted to the RPM database only, so the system cannot become unbootable or otherwise harmed in any case. We're just manipulating "the picture of the system" in the rpm database, not the actual system.)

- Use "yum list installed" and/or "yum list updates" to verify that YUM is happy about the current state, and doesn't want to re-install the package you've just removed.

- After the rpm database has been made to forget the troublesome package, use the file list you made earlier to actually remove the files that once belonged exclusively to the troublesome package. You can even use "rpm -qf " to verify that each file is no longer considered to be belonging to any package before deleting it.

MK

[Steven E. Protter]

Great answer.

Seems the source of the problem was not the libpng libraries but a lack of a LD_LIBRARY_PATH

It would appear based on the tests I've run that there is no danger and I need not take action.

A very good post, going to my favorites library.

SEP