linux-from-scratch/glfs
1
0
Fork 0
mirror of https://github.com/Zeckmathederg/glfs.git synced 2025-01-24 23:32:12 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

Various tagging and typo fixes to the 'Package Management' section

Browse Source 
git-svn-id: svn://svn.linuxfromscratch.org/BLFS/trunk/BOOK@4754 af4574ff-66df-0310-9fd7-8a98e5e911e0
This commit is contained in:
Randy McMurchy 2005-07-21 22:27:23 +00:00
parent 8aefeb6771
commit 4382a367b2
1 changed files with 62 additions and 48 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

110
introduction/important/pkgmgt.xml
View File

@ -54,27 +54,33 @@
<itemizedlist>
<listitem>
<para>If one of the toolchain package (glibc, gcc,
binutils) needs to be upgraded to a newer minor vesion, it is safer to rebuild
LFS. Though you <emphasis>may</emphasis> be able to get by
rebuilding all the packages in their dependency order. We do not recommend it.
For example, if glibc-2.2.x needs to be updated to glibc-2.3.x, it is safer
to rebuild. For micro version updates, a simple reinstallation usually works, but
is not guaranteed. For example, upgrading from glibc-2.3.1 to glibc-2.3.2 will not
usually cause any problems.</para>
<para>If one of the toolchain packages
(<application>Glibc</application>, <application>GCC</application> or
<application>Binutils</application>) needs to be upgraded to a newer
minor vesion, it is safer to rebuild LFS. Though you
<emphasis>may</emphasis> be able to get by rebuilding all the packages
in their dependency order, we do not recommend it. For example, if
glibc-2.2.x needs to be updated to glibc-2.3.x, it is safer to rebuild.
For micro version updates, a simple reinstallation usually works, but
is not guaranteed. For example, upgrading from glibc-2.3.4 to
glibc-2.3.5 will not usually cause any problems.</para>
</listitem>
<listitem>
<para>If a package containing a shared library is updated, and if the
name of the library changes, then all the packages dynamically linked to the
library need to be recompiled to link against the newer library. (Note that there
is no corelation between the package version and the name of the library.) For
example, consider a package foo-1.2.3 that installs a shared library with name
<filename>libfoo.so.1</filename>. Say you upgrade the package to a newer version
foo-1.2.4 that installs a shared library with name <filename>libfoo.so.2</filename>.
In this case, all packages that are dynamically linked to <filename>libfoo.so.1</filename>
need to be recompiled to link against <filename>libfoo.so.2</filename>. Note that
you should not remove the previous libraries till the dependent packages are
recompiled.</para>
name of the library changes, then all the packages dynamically linked
to the library need to be recompiled to link against the newer library.
(Note that there is no correlation between the package version and the
name of the library.) For example, consider a package foo-1.2.3 that
installs a shared library with name
<filename class='libraryfile'>libfoo.so.1</filename>. Say you upgrade
the package to a newer version foo-1.2.4 that installs a shared library
with name <filename class='libraryfile'>libfoo.so.2</filename>. In this
case, all packages that are dynamically linked to
<filename class='libraryfile'>libfoo.so.1</filename> need to be
recompiled to link against
<filename class='libraryfile'>libfoo.so.2</filename>. Note that you
should not remove the previous libraries until the dependent packages
are recompiled.</para>
</listitem>
<listitem>
<para>If you are upgrading a running system, be on the lookout for packages
@ -90,7 +96,7 @@
<title>Package Management Techniques</title>
<para>The following are some common package management techniques. Before
making a decision on a package manager, do a research on the various
making a decision on a package manager, do some research on the various
techniques, particularly the drawbacks of the particular scheme.</para>
<sect3>
@ -109,14 +115,16 @@
<para>This is a simplistic package management that does not need any extra package
to manage the installations. Each package is installed in a separate directory.
For example, package foo-1.1 is installed in <filename>/usr/pkg/foo-1.1</filename>
For example, package foo-1.1 is installed in
<filename class='directory'>/usr/pkg/foo-1.1</filename>
and a symlink is made from <filename>/usr/pkg/foo</filename> to
<filename>/usr/pkg/foo-1.1</filename>. When installing a new version foo-1.2,
it is installed in <filename>/usr/pkg/foo-1.2</filename> and the previous
symlink is replaced by a symlink to the new vesion.</para>
<filename class='directory'>/usr/pkg/foo-1.1</filename>. When installing
a new version foo-1.2, it is installed in
<filename class='directory'>/usr/pkg/foo-1.2</filename> and the previous
symlink is replaced by a symlink to the new version.</para>
<para>The environment variables such as those
mentioned in <xref linkend="intro-important-beyond"/> need to be expanded to
<para>The environment variables such as those mentioned in
<xref linkend="intro-important-beyond"/> need to be expanded to
include <filename>/usr/pkg/foo</filename>. For more than a few packages,
this scheme becomes unmanageable.</para>
@ -125,16 +133,18 @@
<sect3>
<title>Symlink Style Package Management</title>
<para>This is a variation of the previous package management technique. Each package
is installed similar to the previous scheme. But instead of making the symlink,
each file is symlinked into <filename>/usr</filename> hierarchy. This removes the need
to expand the environment variables. Though the symlinks can be created by the user,
to automate the creation, many package managers have been written on this approach.
A few of the popular ones are Stow, Epkg, Graft, and Depot.</para>
<para>This is a variation of the previous package management technique.
Each package is installed similar to the previous scheme. But instead of
making the symlink, each file is symlinked into the
<filename class='directory'>/usr</filename> hierarchy. This removes the
need to expand the environment variables. Though the symlinks can be
created by the user to automate the creation, many package managers have
been written using this approach. A few of the popular ones are Stow,
Epkg, Graft, and Depot.</para>
<para>The installation needs to be faked, so that the package thinks that it is
installed in <filename class="directory">/usr</filename> though in reality it is
installed in <filename class="directory">/usr/pkg</filename> hierarchy.
installed in the <filename class="directory">/usr/pkg</filename> hierarchy.
Installing in this manner is not usually a trivial task. For example, consider
that you are installing a package libfoo-1.1. The following instructions may
not install the package properly:</para>
@ -143,31 +153,35 @@
make
make install</userinput></screen>
<para>The installation will work, but the dependent packages may not link to
libfoo as you would expect. If you compile a package that links against libfoo,
you may notice that it is linked to <filename>/usr/pkg/libfoo/1.1/lib/libfoo.so.1</filename>
instead of <filename>/usr/lib/libfoo.so.1</filename> as you would expect. The correct
approach is to use <envar>DESTDIR</envar> strategy to fake installation of the package.
This approach works as follows:</para>
<para>The installation will work, but the dependent packages may not link
to libfoo as you would expect. If you compile a package that links against
libfoo, you may notice that it is linked to
<filename class='libraryfile'>/usr/pkg/libfoo/1.1/lib/libfoo.so.1</filename>
instead of <filename class='libraryfile'>/usr/lib/libfoo.so.1</filename>
as you would expect. The correct approach is to use <envar>DESTDIR</envar>
strategy to fake installation of the package. This approach works as
follows:</para>
<screen><userinput>./configure --prefix=/usr
make
make DESTDIR=/usr/pkg/libfoo/1.1 install</userinput></screen>
<para>Most of the packages do support this approach, but there are some which do not.
For the non-compliant packages, you may either need to manually install the package,
or you may find that it is easier to install some problematic packages into
<filename>/opt</filename>.</para>
<para>Most of the packages do support this approach, but there are some
which do not. For the non-compliant packages, you may either need to
manually install the package, or you may find that it is easier to install
some problematic packages into
<filename class='directory'>/opt</filename>.</para>
</sect3>
<sect3>
<title>Timestamp Based</title>
<para>In this technique, a file is timestamped before the installation of the package.
After the installation, a simple use of the <command>find</command> command with the
appropriate options can generate a log of all the files installed after the timestamp
file was created. A package manager written with this approach is install-log.</para>
<para>In this technique, a file is timestamped before the installation of
the package. After the installation, a simple use of the
<command>find</command> command with the appropriate options can generate
a log of all the files installed after the timestamp file was created. A
package manager written with this approach is install-log.</para>
<para>Though this scheme has the advantage of being simple, it has two drawbacks.
If during installation, the files are installed with any timestamp other than the
@ -210,11 +224,11 @@ make DESTDIR=/usr/pkg/libfoo/1.1 install</userinput></screen>
<sect3>
<title>User Based Management</title>
<para>This scheme, that is unique to LFS, was devised by Matthias Benkmann,
<para>This scheme, unique to LFS, was devised by Matthias Benkmann,
and is available from the <ulink url="http://www.linuxfromscratch.org/hints/">Hints
Project</ulink>. In this scheme, each package is installed as a separate user
into the standard locations. Files belonging to a package are easily identified
by checking the user id. The features and shortcomings of this approach are
by checking the user ID. The features and shortcomings of this approach are
too complex to describe in this section. For the details please see the hint at <ulink
url="http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt"/>.</para>