193 lines
9.0 KiB
HTML
193 lines
9.0 KiB
HTML
<!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>
|