RPM hell is such a time-waster
The RedHat Package Manager is a tool that takes a package of software resources and deploys them to their correct place within a RH or RH-compatible environment (CentOS, for example), while first checking that anything needed by this package is already present. Unfortunately, knowing whether or not the prerequisites are present depends on an agreement on naming. If a previously installed package recorded that it provides a facility known as “magic”, then subsequent packages that require magic just have to check that magic is already provided.
This works so long as everyone agrees that the name of the facility is “magic”.
Today I bumped into a problem where a complex installation was failing, even though I knew the prerequisites had been satisfied. I had already tested the installation on a test system, with all of the same features already installed. In this case, the magic was “java 1.6”. What I missed, however, was the fact that the clean test environment already came with OpenJDK, which provides Java, and this is detectable by the RPM.
Unfortunately, I was testing against Sun JDK, installed via a .bin, and it did not register that it provided Java, so on the completely clean system the RPM complained about a dependency failure.
It seems that there are many ways to install Java, from different sources, and the names of the facilities these installers provide can vary. They might provide “jdk”, or “jvm”, or “jre”, or “java-jdk” or maybe they may neglect to mention that they provide anything at all. Yet in all cases, Java will be present. It’s just that RPM can’t discover this, and so balks.
The sledgehammer solution is to add –nodeps to the RPM command, but that turns off all dependency checking, which may let through genuine dependency failures and thus make a mess of your environment. A selective nodeps option is not available.
A complex selective work-around is to create a null RPM package that simply provides the “magic”, while performing a proper check that the actual provider of the facility is present (e.g. by searching for specific binaries). What I need is to create an RPM package that claims to provide the necessary version of Java, but in fact merely checks that some other suitable Java is already installed. As I don’t have time, I’ll resort to nodeps.
A better solution would be to coordinate the naming of features across all RPM packages. This, however, introduces a whole lot of other problems such as deciding who has the right to decide the names of the facilities provided by the various packages. Once people are involved, solutions are anything but simple.
Meanwhile I wasted over an hour tracking down dependency issues. Just another drop in an ocean of wasted hours across the industry.
Categorised as: Coding