gronod/lfs
1
0
Fork 0
mirror of https://git.linuxfromscratch.org/lfs.git synced 2025-03-06 06:14:47 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fixed a typo and reversed perspective of explanation in appendix C.

Browse Source 
git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@7537 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
Jeremy Huntwork 2006-04-18 18:27:15 +00:00
parent 72d7e2822e
commit 19abef318e
1 changed files with 8 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
appendixc/dependencies.xml
View File

@ -15,19 +15,20 @@
in order to build and install properly. Some packages even participate
in circular dependencies, that is, the first package depends on the second
which in turn depends on the first. Because of these dependencies, the
order in which packages are built in LFS is very important. This purpose
order in which packages are built in LFS is very important. The purpose
of this page is to document the dependencies of each package built in LFS.</para>
<para>For each package we build, we have listed three types of dependencies.
The first lists what other packages need to be available in order to compile
and install the package in question. The second lists what packages in
addition to the first list need to be available in order to run the
testsuites. The last list of dependencies are packages that need to be built
and installed in their final location before the package in question. In most
cases, this is because the package in question will hardcode paths to other
binaries within scripts that it installs. If not built in a certain order,
this could result in paths of /tools/bin/[binary] being placed inside scripts
installed to the final system. This is obviously not desirable.</para>
testsuites. The last list of dependencies are packages that require this
package to be built and installed in its final location before they are built
and installed. In most cases, this is because these packages will hardcode
paths to binaries within their scripts. If not built in a certain order,
this could result in paths of /tools/bin/[binary] being placed inside
scripts installed to the final system. This is obviously not desirable.
</para>
<!-- Begin Autoconf dependency info -->
<bridgehead renderas="sect2" id="autoconf-dep">Autoconf</bridgehead>