gronod/lfs
1
0
Fork 0
mirror of https://git.linuxfromscratch.org/lfs.git synced 2025-06-18 11:19:19 +01:00
Code Issues Packages Projects Releases Wiki Activity

minor textual changes

Browse Source 
git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@995 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
Mark Hymers 2001-08-18 09:48:20 +00:00
parent 9aecc7d3d2
commit c092a4a32d
2 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
chapter02/download.xml
View File

@ -6,10 +6,10 @@ packages that were downloaded are placed somewhere in $LFS/usr/src.</para>
<para>I use the convention of having a $LFS/usr/src/sources directory. <para>I use the convention of having a $LFS/usr/src/sources directory.
Under sources, I have the directory 0-9 and the directories a Under sources, I have the directory 0-9 and the directories a
through z. A package like sysvinit-2.78.tar.gz is stored under through z. A package like sysvinit-&sysvinit-version;.tar.bz2 is stored under
$LFS/usr/src/sources/s/. A package like bash-2.04.tar.gz is stored under $LFS/usr/src/sources/s/. A package like bash-&bash-version;.tar.bz2 is stored
$LFS/usr/src/sources/b/, and so forth. This convention does not have to be under $LFS/usr/src/sources/b/, and so forth. This convention does not have to
followed, of course; I was just giving an example. It's better to keep be followed, of course; I was just giving an example. It's better to keep
the packages out of $LFS/usr/src and move them to a subdirectory, so the packages out of $LFS/usr/src and move them to a subdirectory, so
we'll have a clean $LFS/usr/src directory in which we will unpack the we'll have a clean $LFS/usr/src directory in which we will unpack the
packages and work with them.</para> packages and work with them.</para>

4
chapter02/install.xml
View File

@ -31,8 +31,8 @@ running:</para>
<para>Some tar programs (most of them nowadays but not all of them) are <para>Some tar programs (most of them nowadays but not all of them) are
slightly modified to be able to use bzip2 files directly using either slightly modified to be able to use bzip2 files directly using either
the I or the y tar parameter, which works the same as the z tar parameter the I, the y or the j tar parameter, which works the same as the z tar
to handle gzip archives. The above construction works no matter how parameter to handle gzip archives. The above construction works no matter how
your host system decided to patch bzip2.</para> your host system decided to patch bzip2.</para>
<para>If a file is just tar'ed, it is unpacked by running:</para> <para>If a file is just tar'ed, it is unpacked by running:</para>