mirror of
https://github.com/Zeckmathederg/glfs.git
synced 2025-01-24 23:32:12 +08:00
5cd0959daa
git-svn-id: svn://svn.linuxfromscratch.org/BLFS/trunk/BOOK@2592 af4574ff-66df-0310-9fd7-8a98e5e911e0
103 lines
4.0 KiB
XML
103 lines
4.0 KiB
XML
<?xml version="1.0" encoding="ISO-8859-1"?>
|
|
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
|
|
<!ENTITY % general-entities SYSTEM "../../general.ent">
|
|
%general-entities;
|
|
]>
|
|
|
|
<sect1 id="intro-important-unpacking">
|
|
<sect1info>
|
|
<othername>$LastChangedBy$</othername>
|
|
<date>$Date$</date>
|
|
</sect1info>
|
|
<?dbhtml filename="unpacking.html"?>
|
|
<title>Notes on downloading, unpacking and compiling software</title>
|
|
|
|
<para>Those people who have built a <acronym>LFS</acronym> system will be aware
|
|
of the general principles of downloading and unpacking software. We will
|
|
however repeat some of that information here for those new to building
|
|
their own software.</para>
|
|
|
|
<para>Each set of installation instructions contains a <acronym>URL</acronym>
|
|
from which you can download the package. We do however keep a selection of
|
|
patches available via http. These are referenced as needed in the
|
|
installation instructions.</para>
|
|
|
|
<para>While you can keep the source <acronym>TAR</acronym> balls anywhere you like, we
|
|
assume that you have unpacked them and unzipped any required patches
|
|
into <filename>/usr/src</filename>.</para>
|
|
|
|
<para>We can not emphasize strongly enough that you should start from a
|
|
<emphasis>clean source tree</emphasis> each time. This means that if
|
|
you have had an error, it's usually best to delete the source tree and
|
|
re-unpack it <emphasis>before</emphasis> trying again. This obviously
|
|
doesn't apply if you're an advanced user used to hacking Makefiles and C
|
|
code, but if in doubt, start from a clean tree.</para>
|
|
|
|
<sect2>
|
|
<title>Unpacking the software</title>
|
|
|
|
<para>If a file is tar'ed and gzip'ed, it is unpacked by running one of
|
|
the following two commands, depending on the filename:</para>
|
|
|
|
<screen><command>tar -xvzf filename.tar.gz
|
|
tar -xvzf filename.tgz
|
|
tar -xvzf filename.tar.Z</command></screen>
|
|
|
|
<para>If a file is tar'ed and bzip2'ed, it can usually be unpacked by
|
|
running:</para>
|
|
|
|
<screen><command>tar -jxvf filename.tar.bz2</command></screen>
|
|
|
|
<para>You can also use a slightly different method:</para>
|
|
|
|
<screen><command>bzcat filename.tar.bz2 | tar -xv</command></screen>
|
|
|
|
<para>Finally, you need to be able to unpack patches which are generally
|
|
not tar'ed. The best way to do this is to copy the patch file to
|
|
<filename>/usr/src</filename> and then to run one of the following
|
|
commands depending on whether the file is .gz or .bz2:</para>
|
|
|
|
<screen><command>gunzip patchname.gz
|
|
bunzip2 patchname.bz2</command></screen>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Verifying file integrity using md5sum</title>
|
|
|
|
<para>Generally, to verify that the downloaded file is genuine and complete,
|
|
most package maintainers also distribute md5sums of the files.
|
|
To verify the md5sum of the downloaded files, download both the file and the
|
|
corresponding md5sum file to the same directory (preferably from different
|
|
on-line locations), and (assuming file.md5sum is the md5sum file downloaded)
|
|
run the following command:</para>
|
|
|
|
<screen><command>md5sum -c file.md5sum</command></screen>
|
|
|
|
<para>If there are any errors, they will be reported.</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Creating Log files during installation</title>
|
|
|
|
<para>For larger packages, it is convenient to create log files instead of
|
|
staring at the screen hoping to catch a particular error or warning. Log files
|
|
are also useful for debugging and keeping records. The following command
|
|
allows you to create an installation log. Replace <command> with the
|
|
command you intend to execute.</para>
|
|
|
|
<screen><command>( <command> 2>&1 | tee compile.log && exit $PIPESTATUS )</command></screen>
|
|
|
|
<para><parameter>2>&1</parameter> redirects error messages
|
|
to the same location as standard output. The <command>tee</command> command
|
|
allows viewing of the output while logging the results to a file. The parentheses
|
|
around the command run the entire command in a subshell and finally the
|
|
<command>exit $PIPESTATUS</command> ensures the result of the <command>
|
|
is returned as the result and not the result of the <command>tee</command> command.</para>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|