RPM Dependency Hell

Adapted from Wikipedia, the free encyclopedia

Dependency hell is a colloquial term for the frustration of some software users who have installed software packages which have dependencies on specific versions of other software packages.  The dependency issues arises around RPM packages, most often libraries. A situation where you can't install Foo 1.X, because it needs Bar 2.3.Y, but you also have Zidget 8.Z installed and that needs Bar 2.2.Y. Long story short, you can have either Foo or Zidget on your system, but not both.

There are various form of "dependency hell" depending on the platform used:

• DLL hell - A form of dependency hell occurring on Microsoft Windows.
• Extension conflict - A form of dependency hell occurring on older versions of Mac OS.
• JAR hell - A form of dependency hell occurring in the Java Runtime Environment.
• RPM hell - A form of dependency hell occurring in the Red Hat distribution of Linux and other distributions that use RPM as a package manager.

Often, rather than "reinventing the wheel", software is designed to take advantage of other software components that are already available, or have already been designed and implemented for use elsewhere. This could be compared to how people building a house might buy off-the-shelf components, such as bricks, windows, and doors, rather than producing everything themselves.

Even for a builder, it can be a problem if a building is designed for a certain door type, and only doors with different specifications are available. However, in the software world, where components evolve rapidly and depend significantly on one another, this problem becomes more pronounced.[2]

The issue of dependency hell may be regarded as an anti-pattern, where the fault lies less with the suppliers of the products than with the framework into which they have to fit.

Dependency hell takes several forms:

An application depends on many libraries.

I try to make a package of a program which is linked to such library (output from ldd):

libwx_baseu-2.8.so.0 => /usr/lib64/wx-2.8-wxcontainer/libwx_baseu-2.8.so.0

Pretty straightforward, right? But when I make a package of this program (with rpmbuild) and then try to install it, rpm complains about missing library (this one above):

error: Failed dependencies:
libwx_baseu-2.8.so.0()(64bit)
libwx_baseu-2.8.so.0(WXU_2.8)(64bit)

My guess is, rpmbuild set the dependency for the main lib directory, i.e. /usr/lib64.

Question -- how to fix this issue (ok, one would be forced install, but I would like to avoid it)? I.e. how to build rpm so the dependencies would set for the wx-2.8-wxcontainer subdirectory (for this library)?

openSUSE 11.4, if this matters.

Edit

I can install such package with --nodeps which forces installation, and after that install program works perfectly. So clearly, rpm or rpmbuild has issues, not the system itself.
 

Side by side installation of multiple versions

The version numbering solution can be improved upon by elevating the version numbering to an operating system supported feature. This allows an application to request a module/library by a unique name and version number constraints, effectively transferring the responsibility for brokering library/module versions from the applications to the operating system. A shared module can then be placed in a central repository without the risk of breaking applications which are dependent on previous or later versions of the module. Each version gets it own entry, side by side with other versions of the same module. This solution is used in Windows operating systems since Windows Vista, where the Global Assembly Cache is an implementation of such a central registry with associated services and integrated with the installation system/package manager.

Smart Package Management

Some package managers can perform smart upgrades, in which interdependent software components are upgraded at the same time, thereby resolving the major number incompatibility issue too.

Many current Linux distributions have also implemented repository-based package management systems to try to solve the dependency problem. These systems are a layer on top of the RPM, dpkg, or other packaging systems that are designed to automatically resolve dependencies by searching in predefined software repositories. Typically these software repositories are FTP sites or websites, directories on the local computer or shared across a network or, much less commonly, directories on removable media such as CDs or DVDs. This eliminates dependency hell for software packaged in those repositories, which are typically maintained by the Linux distribution provider and mirrored worldwide. Although these repositories are often huge it is not possible to have every piece of software in them, so dependency hell can still occur. In all cases, dependency hell is still faced by the repository maintainers.

Examples of these systems include Apt and Yum,

Because different pieces of software have different dependencies, it is possible to get into a vicious circle of dependency requirements, or (possibly worse) an ever-expanding tree of requirements, as each new package demands several more be installed. Systems such as Debian's APT can resolve this by presenting the user with a range of solutions, and allowing the user to accept or reject the solutions, as desired. Easy Adaptability in ProgrammingIf application software is designed in such a way that its programmers are able to easily adapt the interface layer that deals with the OS, window manager or desktop environment to new or changing standards, then the programmers would only have to monitor notifications from the environment creators or component library designers and quickly adjust their software with updates for their users, all with minimal effort and a lack of costly and time-consuming redesign. This method would encourage programmers to pressure those upon whom they depend to maintain a reasonable notification process that is not onerous to anyone involved.Software appliancesAnother approach to avoiding dependency issues is to deploy applications as a software appliance. A software appliance encapsulates dependencies in a pre-integrated self-contained unit such that users no longer have to worry about resolving software dependencies. Instead the burden is shifted to developers of the software appliance.

Portable applicationsAn application (or version of an existing conventional application) that is completely self-contained and requires nothing to be already installed. It is coded to have all necessary components included, or is designed to keep all necessary files within its own directory, and will not create a dependency problem. These are often able to run independently of the system to which they are connected.

NEWS CONTENTS

• 190318 : Handling RPM dependency hell ( Handling RPM dependency hell, )
• 190318 : The New rpm Hell -or- Why yum and pup Seem To Be So Broken In Fedora by Caitlyn Martin ( June 6, 2006 , DevCenter Blog )
• 190318 : Is Linux Annoying - OReilly Media ( Is Linux Annoying - O'Reilly Media, )

Old News ;-)

Handling RPM dependency hell

11/04/2003

An easy way to install RPMs along with associated dependencies is to use yum (Yellow dog Updater, Modified) or apt for RPM. Of the two products, I would recommend using yum, as it has a smaller code base than apt for RPM, it is written in python (similar to Red Hat's anaconda installer), and it makes upgrading to new Red Hat releases relatively easy (apt for RPM has a dist-upgrade feature, but I have never tried it).

Red Hat Linux's up2date command will also install Red Hat's RPMs along with dependencies. However, up2date is not as flexible in incorporating third-party RPMs, such as those at freshrpms.net.

Older notes on apt for RPM

The following instructions will install apt from freshrpms.net with Red Hat Linux 8.0.

rpm -Uvh http://ftp.freshrpms.net/pub/freshrpms/psyche/apt/apt-0.5.4cnc9-fr1.i386.rpm

Update the list of available RPMs:
apt-get update

Upgrade your system to the latest package versions:
apt-get upgrade

I run apt-get update and apt-get upgrade daily on non-critical systems. Although I think Red Hat's quality assurance with updated packages is outstanding, you may not wish to upgrade RPMs automatically on a production system.

Root crontab entry to update your system daily:
# Update system
0 4 * * * /usr/bin/apt-get update && /usr/bin/apt-get upgrade -y

Search for installable packages with a regular expression (regex):
apt-cache search regex

Install a package and associated dependencies:
apt-get install package

Remove a package:
apt-get remove package

Display information about a package:
apt-cache show package

If you see "The following packages have been kept back" when running apt-get upgrade, it means that an additional package needs to be installed in order to upgrade the package. Run apt-get -f install package to upgrade the package.

Example:

The following packages have been kept back
iptables perl

# apt-get -f install iptables perl
Reading Package Lists... Done
Building Dependency Tree... Done
The following extra packages will be installed:
kernel#2.4.20-20.7 perl-CGI perl-CPAN perl-DB_File perl-NDBM_File
perl-suidperl
The following packages will be upgraded
iptables perl
The following NEW packages will be installed:
kernel#2.4.20-20.7 perl-CGI perl-CPAN perl-DB_File perl-NDBM_File
perl-suidperl
2 packages upgraded, 6 newly installed, 0 removed and 1 not upgraded.
Need to get 20.6MB of archives.
After unpacking 33.2MB of additional disk space will be used.
Do you want to continue? [Y/n] Y

Older notes on rpmdb-redhat package

The above procedure works well if the RPM is part of the Red Hat Linux distribution or a third-party package maintainer like freshrpms.net. However, if you are installing an RPM from another source, you may have to manually determine which packages satisfy dependencies.

Note: the following example was written when using Red Hat Linux 7.2.

First of all, make sure you have the rpmdb-redhat package installed:

rpm -q rpmdb-redhat
rpmdb-redhat-7.2-0.20010924

If you do not have the package installed, install it using apt with apt-get install rpmdb-redhat.

In this example, I will install the Cheops RPM from ftp://ftp.marko.net/pub/cheops/RPMS/cheops-0.59a-1.i386.rpm

First, I'll use rpm -Uvh to install the RPM:

rpm -Uvh cheops-0.59a-1.i386.rpm
error: failed dependencies:
libgdk.so.1 is needed by cheops-0.59a-1
libglib.so.1 is needed by cheops-0.59a-1
libgtk.so.1 is needed by cheops-0.59a-1

In this case, I am missing three dependencies (shared libraries) necessary for installing the cheops RPM. We can use RPM's --redhatprovides flag to determine which Red Hat-supplied RPMs would satisfy these dependencies:

rpm --redhatprovides libgdk.so.1
gtk+10-1.0.6-10
rpm --redhatprovides libglib.so.1
glib10-1.0.6-10
rpm --redhatprovides libgtk.so.1
gtk+10-1.0.6-10

The missing dependencies are contained within the gtk+10 and glib10 RPMs. Install the two RPMs with the apt-get install gtk+10 glib10 command.

Verify that the packages are installed:

rpm -q glib10 gtk+10
glib10-1.0.6-10
gtk+10-1.0.6-10

We can now install the Cheops RPM:
rpm -Uvh cheops-0.59a-1.i386.rpm
Preparing... ########################################### [100%]
1:cheops ########################################### [100%]

The New rpm Hell -or- Why yum and pup Seem To Be So Broken In FedoraThe New rpm Hell -or- Why yum and pup Seem To Be So Broken In Fedora by Caitlyn Martin

June 6, 2006 | DevCenter Blog

Since I reviewed Fedora Core 5 back in April I've become increasingly frustrated with one aspect of what is otherwise a very well done distribution: package management and keeping my system secure and up to date. I've run into repeated instances of yum deciding I needed a lot of new packages and promptly failing over just one. pup, which is really just a pretty but somewhat crippled front end to yum, also fails in the same way. What I've discovered is that pup and yum aren't broken at all. The code is doing precisely what it was designed to do.

Let's look at today's failure as an example. I had been on vacation and my system was probably 10 days behind on updates. yum decided I needed to upgrade some 166 packages and add 2 more for dependencies. Fine, go do it. No chance. Here is the error message:

Error: Missing Dependency: libecal-1.2.so.3 is needed by package gnome-panel

That seems clear enough but it really isn't. gnome-panel wasn't being upgraded. Rather the package that contained libecal-1.2.so.3 was and doing the upgrade would break gnome-panel. Typing in:

yum whatprovides libecal-1.2.so.3

reveals that it is part of the evolution-data-server package. A new version of that package was rolled out without checking to see if any other package had a dependency on the old version. That is just plain sloppy package and repository management on the part of the Fedora Project people at Red Hat. If this happened just once it would be forgivable but this sort of failure has happened repeatedly over the past two months. To their credit the Fedora Project has, in each case, rolled out a new package for whatever they've broken in a day or two. Still, it shouldn't happen in the first place.

Even worse, for Joe or Jane average desktop user who wants to click on the pretty pup icon and not think about what lies beneath this likely means that their system will remain unpatched and/or they will conclude that Fedora, or worse, Linux in general. is broken and unreliable despite the lack of any bug in the code. Remember that pup, unlike the up2date program it replaced, has no provision for choosing what to update and what to skip. To fix this you have to work at the command line, period.

Oh, yeah, the workaround is to run your yum update or upgrade as follows:

yum --exclude=<package name> update

In the example above you'd replace <package name> with evolution-data-server and the rest of the updates would work provided there are no dependencies on the new package. Yes, you can have conflicting and truly unresolvable dependencies, much like the bad old days of rpm hell circa 1998 or so.

Some of you people who have been reading my articles know that I've given up on Gnome for now. Why not simply uninstall gnome-panel? Well… while I clearly don't need the panel itself the package gnome-panel contains a library needed by gtk-sharp2. Yep, removing the panel breaks mono. If I try and remove the gtk-sharp2 package as well I break other apps, such as f-spot. This is why I generally end up with lots of extra cruft on a Fedora or Red Hat installation: lots of interlinking dependencies.

This truly is reminiscent of rpm hell except that this time rpm really and truly isn't to blame. rpm really works well nowadays and yum is a decent tool for automating package management. The good folks at Red Hat need to realize that while Fedora doesn't generate revenue in and of itself it is the test bed for Red Hat Enterprise Linux (RHEL) and they really need a large user base pounding on it. If basic functionality is managed so poorly as to make the distribution a pain to administer people will choose to run something else. Getting Fedora Core packages that work together out at the same time is an absolute must.

Is Linux Annoying - O'Reilly Media

Let's consider software packaging. This is something that all platforms have to deal with. Everyone has a love-hate relationship with software packaging since it can relate to something as simple as installing binaries for Mac OS X to something a bit more complex, unpacking and building source code from scratch on Linux, or anything in between. Any number of issues can crop up depending on what method or operating system is being used.

Since several Linux vendors have selected to use RPM as their packaging solution, it only stands to reason that people would find issues with how RPM works.

On the Linux Annoyances mailing list, John Andersen suggested the following method for dealing with what is commonly known as RPM Hell:

You try to install XYZ package but it has a prerequisite for abc.lib.so.7.

You take a swig of beer.

You Google around a bit and find that abc.lib.so.7 is supplied by package abc-2.19-45.rpm.

You hunt around for that RPM on the Web (since a quick ls abc* | less on the distribution CD didn't turn up anything) and you find it on a Bulgarian web site and download it.

You try to install it, and it requires lib-hij.so.2.

You take a swig of beer.

You Google around a bit and find that lib-hij.so.2 is supplied by package efg-5.10-54.rpm.

You hunt around for that RPM on the Web (those dang CDs again) and you find it on an Australian web site and download it.

You try to install it, and it requires lib-klm.so.1.

You take a swig of beer.

"Hmm", you think to yourself, "maybe I'll just download and compile the source code".

No good, the configure script will just die on you, with unresolved externals and more prerequisites.

In John's immortal words, "The whole experience sours one on the whole concept and were it not for the beer, would lead to many suicides and divorces."

And no, before you ask, this isn't just some clever college drinking game. I'm not advocating drinking on the job; after all, one bookshelf starts to look like another to any drunken bookstore clerk. But drinking is tempting when you have to configure a half dozen servers in a nightlong install-fest.

Surely, there has to be another way to install software without using a different operating system or Linux distribution not built on RPM. Sometimes using another platform just isn't an option.

In the philosophy of the Annoyances books, if we take it upon ourselves to understand the annoyances of a particular problem and instead of just giving up, we position ourselves better for dealing with the problem at hand.

Another poster, Alex Butcher, suggests the following process for avoiding RPM Hell:

Stick to RPMs built for the distribution you're running. If in need of a package from an outside source, try a third-party RPM repository dedicated to the Linux distribution you have on hand. For example, the following websites focus on packages for Red Hat's distributions of Linux:

• http://freshRPMs.net/
• http://ftp.falsehope.com/
• http://www.fedora.us/

Moreover, Alex points out, if you do need a package for which no RPMs are available, try the following:

Take the source RPM for a similar distribution or from a later version of the same distribution.

Adjust any explicit dependencies in the .spec file.

Rebuild the binary for your distribution.

Of course, Alex admits that this process is easier said than done, but points out that it becomes quite straightforward with a bit of practice and a little knowledge from the RPM documentation.

Finally Alex suggests that before using a third-party RPM or rolling your own, double check that the file or package needed isn't included on hand after all.

Red Hat, for example, includes a fully populated RPM database that can be queried using the --redhatprovides and --redhatrequires command line options. Simply install the rpmdb-redhat package beforehand.

$ rpm -install rpmdb-redhat-9-0.20030227.i386.rpm

$ rpm --redhatprovides libxml
libxml-1.8.17-8

$ rpm --redhatrequires libxml
GConf-1.0.9-10
bonobo-1.0.22-4
dia-0.90-11
galeon-1.2.7-3
gnome-pilot-0.1.71-2
gnome-print-0.37-4
libglade-0.17-11
libgnomeprint-1.116.0-6
libgnomeprint22-2.2.1.1-3
librsvg-1.0.2-8
libxml-devel-1.8.17-8
mrproject-0.9-4
soup-0.7.10-4

In three easy steps you can find out which Red Hat package provides libxml and which packages require libxml . Another option is to create a local listing of RPMs on hand using rpm's query option.

$ rpm -qilp /mnt/cdrom/RedHat/RPMS/* >
install_cd_1.txt

Then if you come across a package that has a specific requirement, you can quickly grep a personal list of RPMs to find the proper package. For our little Red Hat Linux 9 system you can see that if libxml version 1.8.17-8 is needed you can find the proper file on the Red Hat Install CD 1.

$ cat install_cd_1.txt | grep libxml | less

Name        : libxml                      Relocations : (not relocateable)

Group       : System Environment/Libraries Source RPM : libxml-1.8.17-8.src.rpm
The libxml package contains an XML library, which allows you to
/usr/lib/libxml.so.1
/usr/lib/libxml.so.1.8.17
/usr/share/doc/libxml-1.8.17
/usr/share/doc/libxml-1.8.17/AUTHORS
/usr/share/doc/libxml-1.8.17/COPYING
/usr/share/doc/libxml-1.8.17/COPYING.LIB
/usr/share/doc/libxml-1.8.17/ChangeLog
/usr/share/doc/libxml-1.8.17/NEWS
/usr/share/doc/libxml-1.8.17/README
/usr/share/doc/libxml-1.8.17/TODO

Of course the real advantage of this last option is the ability to create a listing of RPMs from any source of RPMs for future searches.

At the core is the simple idea of presenting solutions that enable you both to customize and troubleshoot, to borrow from Karp's introduction again. Just because Linux may be the least annoying solution for a problem, it does not follow that a Linux system has no idiosyncrasies to deal with. After all, there is no "one true operating system".

All of this highlights the perspective of the free and open source philosophies: users are as empowered as anyone else. We are not here to complain or to criticize but to learn, understand, and fix.

Recommended Links

Softpanorama Recommended

Top articles

Sites

• RPM Hell
• Rpm Hell
• Handling RPM dependency hell
• Insufficiently Random Eclipse is the new RPM hell
• Yum (Yellowdog Updater, Modified) HOWTO Introduction
• The New rpm Hell -or- Why yum and pup Seem To Be So Broken In Fedora - O'Reilly Linux DevCenter Blog
• rpm hell is right - Bart's Blog
• homepage.smc.edu yum – yellowdog updater automatic package management by David Margan

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March, 12, 2019