Next Previous Contents

4. Prepackaged Binaries

4.1 Whats wrong with rpms?

Manually building and installing packages from source is apparently so daunting a task for some Linux users that they have embraced the popular rpm and deb or the newer Stampede slp package formats. While it may be the case that an rpm install normally runs as smoothly and as fast as a software install in a certain other notorious operating system, some thought should certainly be given to the disadvantages of self-installing, prepackaged binaries.

First, be aware that software packages are normally released first as "tarballs", and that prepackaged binaries follow days, weeks, even months later. A current rpm package is typically at least a couple of minor version behind the latest "tarball". So, if you wish to keep up with all the 'bleeding edge' software, you might not wish to wait for an rpm or deb to appear. Some less popular packages may never be rpm'ed.

Second, the "tarball" package may well be more complete, have more options, and lend itself better to customization and tweaking. The binary rpm version may be missing some of the functionality of the full release. Source rpm's contain the full source code and are equivalent to the corresponding "tarballs", and they likewise need to be built and installed using either of the rpm --recompile packagename.rpm or rpm --rebuild packagename.rpm options.

Third, some prepackaged binaries will not properly install, and even if they do install, they could crash and core-dump. They may depend on different library versions than are present in your system, or they may be improperly prepared or just plain broken. In any case, when installing an rpm or deb you necessarily trust the expertise of the persons who have packaged it.

Finally, it helps to have the source code on hand, to be able to tinker with and learn from it. It is much more straightforward to have the source in the archive you are building the binaries from, and not in a separate source rpm.

Installing an rpm package is not necessarily a no-brainer. If there is a dependency conflict, an rpm install will fail. Likewise, should the rpm require a different version of libraries than the ones present on your system, the install may not work, even if you create symbolic links to the missing libraries from the ones in place. Despite their convenience, rpm installs often fail for the same reasons "tarball" ones do.

You must install rpm's and deb's as root, in order to have the necessary write permissions, and this opens a potentially serious security hole, as you may inadvertently clobber system binaries and libraries, or even install a Trojan horse that might wreak havoc upon your system. It is therefore important to obtain rpm and deb packages from a "trusted source". In any case, you should run a 'signature check' (against the MD5 checksum) on the package, rpm --checksig packagename.rpm, before installing. Likewise highly recommended is running rpm -K --nopgp packagename.rpm. The corresponding commands for deb packages are dpkg -I | --info packagename.deb and dpkg -e | --control packagename.deb.

For the truly paranoid (and, in this case there is much to be said for paranoia), there are the unrpm and rpmunpack utilities available from the Sunsite utils/package directory for unpacking and checking the individual components of the packages.

Klee Diene has written an experimental dpkgcert package for verifying the integrity of installed .deb files against MD5 checksums. It is available from the Debian ftp archive. The current package name / version is dpkgcert_0.2-4.1_all.deb. The Jim Pick Software site maintains an experimental server database to provide dpkgcert certificates for the packages in a typical Debian installation.

In their most simple form, the commands rpm -i packagename.rpm and dpkg --install packagename.deb automatically unpack and install the software. Exercise caution, though, since using these commands blindly may be dangerous to your system's health!

Note that the above warnings also apply, though to a lesser extent, to Slackware's pkgtool installation utility. All "automatic" software installations require caution.

The martian and alien programs allow conversion between the rpm, deb, Stampede slp, and tar.gz package formats. This makes these packages accessible to all Linux distributions.

Carefully read the man pages for the rpm and dpkg commands, and refer to the RPM HOWTO, TFUG's Quick Guide to Red Hat's Package Manager, and The Debian Package Management Tools for more detailed information.

4.2 Problems with rpms: an example

Jan Hubicka wrote a very nice fractal package called xaos. At his home page, both .tar.gz and rpm packages are available. For the sake of convenience, let us try the rpm version, rather than the "tarball".

Unfortunately, the rpm of xaos fails to install. Two separate rpm versions misbehave.

rpm -i --test XaoS-3.0-1.i386.rpm 

error: failed dependencies:
        libslang.so.0 is needed by XaoS-3.0-1
        libpng.so.0 is needed by XaoS-3.0-1
        libaa.so.1 is needed by XaoS-3.0-1

rpm -i --test xaos-3.0-8.i386.rpm 

error: failed dependencies:
        libaa.so.1 is needed by xaos-3.0-8

The strange thing is that libslang.so.0, libpng.so.0, and libaa.so.1 are all present in /usr/lib on the system tested. The rpms of xaos must have been built with slightly different versions of those libraries, even if the release numbers are identical.

As a test, let us try installing xaos-3.0-8.i386.rpm with the --nodeps option to force the install. A trial run of xaos crashes. 

xaos: error in loading shared libraries: xaos: undefined symbol: __fabsl

Let us stubbornly try to get to the bottom of this. Running ldd on the xaos binary to find its library dependencies shows all the necessary shared libraries present. Running nm on the /usr/lib/libaa.so.1 library to list its symbolic references shows that it is indeed missing __fabsl. Of course, the absent reference could be missing from one of the other libraries... There is nothing to be done about that, short of replacing one or more libraries.

Enough! Download the "tarball", XaoS-3.0.tar.gz, available from the ftp site, as well as from the home page. Try building it. Running ./configure, make, and finally (as root) make install, works flawlessly.

This is one of an number of examples of prepackaged binaries being more trouble than they are worth.

Next Previous Contents

Hosting by: Hurra Communications Ltd.
Generated: 2007-01-26 17:57:48