<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <HTML> <HEAD> <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9"> <TITLE>Building and Installing Software Packages for Linux: Prepackaged Binaries</TITLE> <LINK HREF="Software-Building-HOWTO-5.html" REL=next> <LINK HREF="Software-Building-HOWTO-3.html" REL=previous> <LINK HREF="Software-Building-HOWTO.html#toc4" REL=contents> </HEAD> <BODY> <A HREF="Software-Building-HOWTO-5.html">Next</A> <A HREF="Software-Building-HOWTO-3.html">Previous</A> <A HREF="Software-Building-HOWTO.html#toc4">Contents</A> <HR> <H2><A NAME="s4">4. Prepackaged Binaries</A></H2> <P> <P> <H2><A NAME="ss4.1">4.1 Whats wrong with rpms?</A> </H2> <P> <P>Manually building and installing packages from source is apparently so daunting a task for some Linux users that they have embraced the popular <EM>rpm</EM> and <EM>deb</EM> or the newer Stampede <EM>slp</EM> package formats. While it may be the case that an <EM>rpm</EM> 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. <P>First, be aware that software packages are normally released first as "tarballs", and that prepackaged binaries follow days, weeks, even months later. A current <EM>rpm</EM> 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 <EM>rpm</EM> or <EM>deb</EM> to appear. Some less popular packages may never be <EM>rpm</EM>'ed. <P>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 <EM>rpm</EM>'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 <B>rpm --recompile packagename.rpm</B> or <B>rpm --rebuild packagename.rpm</B> options. <P>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 <EM>rpm</EM> or <EM>deb</EM> you necessarily trust the expertise of the persons who have packaged it. <P>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 <EM>rpm</EM>. <P> <P>Installing an <EM>rpm</EM> package is not necessarily a no-brainer. If there is a dependency conflict, an <EM>rpm</EM> install will fail. Likewise, should the <EM>rpm</EM> 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, <EM>rpm</EM> installs often fail for the same reasons "tarball" ones do. <P>You must install <EM>rpm</EM>'s and <EM>deb</EM>'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 <EM>Trojan horse</EM> that might wreak havoc upon your system. It is therefore important to obtain <EM>rpm</EM> and <EM>deb</EM> packages from a "trusted source". In any case, you should run a 'signature check' (against the MD5 checksum) on the package, <B>rpm --checksig packagename.rpm</B>, before installing. Likewise highly recommended is running <B>rpm -K --nopgp packagename.rpm</B>. The corresponding commands for <EM>deb</EM> packages are <B>dpkg -I | --info packagename.deb</B> and <B>dpkg -e | --control packagename.deb</B>. <P> <UL> <LI><CODE>rpm --checksig gnucash-1.1.23-4.i386.rpm</CODE> <BLOCKQUOTE><CODE> <PRE> </PRE> </CODE></BLOCKQUOTE> <CODE>gnucash-1.1.23-4.i386.rpm: size md5 OK</CODE></LI> </UL> <P> <UL> <LI><CODE>rpm -K --nopgp gnucash-1.1.23-4.i386.rpm</CODE> <BLOCKQUOTE><CODE> <PRE> </PRE> </CODE></BLOCKQUOTE> <CODE>gnucash-1.1.23-4.i386.rpm: size md5 OK</CODE></LI> </UL> <P>For the truly paranoid (and, in this case there is much to be said for paranoia), there are the <EM>unrpm</EM> and <EM>rpmunpack</EM> utilities available from the <A HREF="ftp://metalab.unc.edu/pub/Linux/utils/package">Sunsite utils/package directory</A> for unpacking and checking the individual components of the packages. <P> <A HREF="mailto:klee@debian.org">Klee Diene</A> has written an experimental <EM>dpkgcert</EM> package for verifying the integrity of installed <EM>.deb</EM> files against MD5 checksums. It is available from the <A HREF="ftp://ftp.debian.org/pub/debian/project/experimental">Debian ftp archive</A>. The current package name / version is <EM>dpkgcert_0.2-4.1_all.deb</EM>. The <A HREF="http://dpkgcert.jimpick.com">Jim Pick Software</A> site maintains an experimental server database to provide <EM>dpkgcert</EM> certificates for the packages in a typical Debian installation. <P>In their most simple form, the commands <B>rpm -i packagename.rpm</B> and <B>dpkg --install packagename.deb</B> automatically unpack and install the software. Exercise caution, though, since using these commands blindly may be dangerous to your system's health! <P>Note that the above warnings also apply, though to a lesser extent, to Slackware's <EM>pkgtool</EM> installation utility. All "automatic" software installations require caution. <P>The <A HREF="http://www.people.cornell.edu/pages/rc42/program/martian.html">martian</A> and <A HREF="http://kitenet.net/programs/alien/">alien</A> programs allow conversion between the <EM>rpm</EM>, <EM>deb</EM>, Stampede <EM>slp</EM>, and <EM>tar.gz</EM> package formats. This makes these packages accessible to all Linux distributions. <P>Carefully read the man pages for the <EM>rpm</EM> and <EM>dpkg</EM> commands, and refer to the <A HREF="ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/RPM-HOWTO">RPM HOWTO</A>, TFUG's <A HREF="http://www.tfug.org/helpdesk/linux/rpm.html">Quick Guide to Red Hat's Package Manager</A>, and <A HREF="http://www.debian.org/doc/FAQ/debian-faq-7.html">The Debian Package Management Tools</A> for more detailed information. <P> <P> <H2><A NAME="ss4.2">4.2 Problems with rpms: an example</A> </H2> <P> <P> <A HREF="mailto:hubicka@paru.cas.cz">Jan Hubicka</A> wrote a very nice fractal package called <EM>xaos</EM>. At his <A HREF="http://www.paru.cas.cz/~hubicka/XaoS">home page</A>, both <CODE>.tar.gz</CODE> and <CODE>rpm</CODE> packages are available. For the sake of convenience, let us try the rpm version, rather than the "tarball". <P>Unfortunately, the rpm of <EM>xaos</EM> fails to install. Two separate rpm versions misbehave. <P><B>rpm -i --test XaoS-3.0-1.i386.rpm</B> <BLOCKQUOTE><CODE> <PRE> 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 </PRE> </CODE></BLOCKQUOTE> <P><B>rpm -i --test xaos-3.0-8.i386.rpm</B> <BLOCKQUOTE><CODE> <PRE> error: failed dependencies: libaa.so.1 is needed by xaos-3.0-8 </PRE> </CODE></BLOCKQUOTE> <P>The strange thing is that <CODE>libslang.so.0</CODE>, <CODE>libpng.so.0</CODE>, and <CODE>libaa.so.1</CODE> are all present in <CODE>/usr/lib</CODE> on the system tested. The rpms of <EM>xaos</EM> must have been built with slightly different versions of those libraries, even if the release numbers are identical. <P>As a test, let us try installing <CODE>xaos-3.0-8.i386.rpm</CODE> with the <EM>--nodeps</EM> option to force the install. A trial run of <EM>xaos</EM> crashes. <BLOCKQUOTE><CODE> <PRE> xaos: error in loading shared libraries: xaos: undefined symbol: __fabsl </PRE> </CODE></BLOCKQUOTE> <P>Let us stubbornly try to get to the bottom of this. Running <EM>ldd</EM> on the <EM>xaos</EM> binary to find its library dependencies shows all the necessary shared libraries present. Running <EM>nm</EM> on the <CODE>/usr/lib/libaa.so.1</CODE> library to list its symbolic references shows that it is indeed missing <EM>__fabsl</EM>. Of course, the absent reference <EM>could</EM> be missing from one of the other libraries... There is nothing to be done about that, short of replacing one or more libraries. <P>Enough! Download the "tarball", <CODE>XaoS-3.0.tar.gz</CODE>, available from the <A HREF="ftp://ftp.ta.jcu.cz/pub/linux/hubicka/XaoS/3.0">ftp site</A>, as well as from the home page. Try building it. Running <B>./configure</B>, <B>make</B>, and finally (as root) <B>make install</B>, works flawlessly. <P>This is one of an number of examples of prepackaged binaries being more trouble than they are worth. <P> <P> <P> <P> <HR> <A HREF="Software-Building-HOWTO-5.html">Next</A> <A HREF="Software-Building-HOWTO-3.html">Previous</A> <A HREF="Software-Building-HOWTO.html#toc4">Contents</A> </BODY> </HTML>