Wandering Thoughts archives


RPM's multi-architecture file ownership problem

An increasing number of Red Hat/Fedora machines are dual architecture: they run both 64-bit and 32-bit x86 programs, and thus need to have shared libraries and RPMs and so on for both of them. This can expose some interesting issues when installing and upgrading RPMs; one of them is the dual architecture file ownership problem.

There are a lot of RPMs that install both architecture-dependent files like binaries and shared libraries and architecture-independent files like header files and manpages. The architecture dependent files already go into different places, so you can easily install both the x86 and x86_64 versions at the same time, but the same is not true of architecture-independent files; there is only one /usr/share/man.

The RPM people decided that the easiest solution to this problem was to allow more than one RPM to supply the same file, provided that all versions of the file were exactly the same. That way, if libfoo.x86 and libfoo.x86_64 provide exactly the same manpages, they can coexist, and anyways there's no reason for the manpages to be different just because of the architecture you built the RPM for; such differences are effectively a bug.

However, this has a side effect: you usually have to upgrade the RPMs for both architectures at the same time, because there is no guarantee that libfoo-1.1.x86 will have the same manpages as libfoo-1.2.x86_64. If you can't do this (perhaps all the necessary RPMs aren't in the updates repository yet), you get weird errors about how files from libfoo-1.2 conflict with files from libfoo-1.1 (unhelpfully, yum doesn't tell you the architectures of the RPMs involved).

Sometimes you can deal with this by removing the RPM for the unavailable library, but sometimes you really do need the x86 version of libfoo and you're stuck until libfoo-1.2.x86 gets built and pushed out.

In fact, if you stick to well-run repositories, file conflict errors on a dual architecture machine are almost always the sign of an architecture clash. Well run repositories just don't normally allow RPMs with clashing files, so the only way to get a file clash is because yum is somehow pulling in an RPM from the wrong architecture. (Unfortunately, hunting down where and why can be challenging.)

linux/RPMMultiarchFileProblem written at 23:08:37; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.