diff options
Diffstat (limited to 'chapter06/pkgmgt.xml')
| -rw-r--r-- | chapter06/pkgmgt.xml | 291 |
1 files changed, 0 insertions, 291 deletions
diff --git a/chapter06/pkgmgt.xml b/chapter06/pkgmgt.xml deleted file mode 100644 index d28038467..000000000 --- a/chapter06/pkgmgt.xml +++ /dev/null @@ -1,291 +0,0 @@ -<?xml version="1.0" encoding="ISO-8859-1"?> -<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" - "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ - <!ENTITY % general-entities SYSTEM "../general.ent"> - %general-entities; -]> - -<sect1 id="ch-system-pkgmgt"> - <?dbhtml filename="pkgmgt.html"?> - - <title>Package Management</title> - - <para>Package Management is an often requested addition to the LFS Book. A - Package Manager allows tracking the installation of files making it easy to - remove and upgrade packages. As well as the binary and library files, a - package manager will handle the installation of configuration files. Before - you begin to wonder, NO—this section will not talk about nor recommend - any particular package manager. What it provides is a roundup of the more - popular techniques and how they work. The perfect package manager for you may - be among these techniques or may be a combination of two or more of these - techniques. This section briefly mentions issues that may arise when upgrading - packages.</para> - - <para>Some reasons why no package manager is mentioned in LFS or BLFS - include:</para> - - <itemizedlist> - <listitem> - <para>Dealing with package management takes the focus away from the goals - of these books—teaching how a Linux system is built.</para> - </listitem> - - <listitem> - <para>There are multiple solutions for package management, each having - its strengths and drawbacks. Including one that satisfies all audiences - is difficult.</para> - </listitem> - </itemizedlist> - - <para>There are some hints written on the topic of package management. Visit - the <ulink url="&hints-index;">Hints Project</ulink> and see if one of them - fits your need.</para> - - <sect2> - <title>Upgrade Issues</title> - - <para>A Package Manager makes it easy to upgrade to newer versions when they - are released. Generally the instructions in the LFS and BLFS Book can be - used to upgrade to the newer versions. Here are some points that you should - be aware of when upgrading packages, especially on a running system.</para> - - <itemizedlist> - <listitem> - <para>If Glibc needs to be upgraded to a newer version, (e.g. from - glibc-2.19 to glibc-2.20), it is safer to rebuild LFS. Though you - <emphasis>may</emphasis> be able to rebuild all the packages in their - dependency order, we do not recommend it. </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 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> - </itemizedlist> - - </sect2> - - <sect2> - <title>Package Management Techniques</title> - - <para>The following are some common package management techniques. Before - making a decision on a package manager, do some research on the various - techniques, particularly the drawbacks of the particular scheme.</para> - - <sect3> - <title>It is All in My Head!</title> - - <para>Yes, this is a package management technique. Some folks do not find - the need for a package manager because they know the packages intimately - and know what files are installed by each package. Some users also do not - need any package management because they plan on rebuilding the entire - system when a package is changed.</para> - - </sect3> - - <sect3> - <title>Install in Separate Directories</title> - - <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 class='directory'>/usr/pkg/foo-1.1</filename> - and a symlink is made from <filename>/usr/pkg/foo</filename> to - <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>Environment variables such as <envar>PATH</envar>, - <envar>LD_LIBRARY_PATH</envar>, <envar>MANPATH</envar>, - <envar>INFOPATH</envar> and <envar>CPPFLAGS</envar> need to be expanded to - include <filename>/usr/pkg/foo</filename>. For more than a few packages, - this scheme becomes unmanageable.</para> - - </sect3> - - <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 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 include 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 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> - -<screen role="nodump"><userinput>./configure --prefix=/usr/pkg/libfoo/1.1 -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 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 the - <envar>DESTDIR</envar> strategy to fake installation of the package. This - approach works as follows:</para> - -<screen role="nodump"><userinput>./configure --prefix=/usr -make -make DESTDIR=/usr/pkg/libfoo/1.1 install</userinput></screen> - - <para>Most packages 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>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 current time, those files will not be tracked by - the package manager. Also, this scheme can only be used when one package - is installed at a time. The logs are not reliable if two packages are - being installed on two different consoles.</para> - - </sect3> - - <sect3> - <title>Tracing Installation Scripts</title> - - <para>In this approach, the commands that the installation scripts perform - are recorded. There are two techniques that one can use:</para> - - <para>The <envar>LD_PRELOAD</envar> environment variable can be set to - point to a library to be preloaded before installation. During - installation, this library tracks the packages that are being installed by - attaching itself to various executables such as <command>cp</command>, - <command>install</command>, <command>mv</command> and tracking the system - calls that modify the filesystem. For this approach to work, all the - executables need to be dynamically linked without the suid or sgid bit. - Preloading the library may cause some unwanted side-effects during - installation. Therefore, it is advised that one performs some tests to - ensure that the package manager does not break anything and logs all the - appropriate files.</para> - - <para>The second technique is to use <command>strace</command>, which - logs all system calls made during the execution of the installation - scripts.</para> - </sect3> - - <sect3> - <title>Creating Package Archives</title> - - <para>In this scheme, the package installation is faked into a separate - tree as described in the Symlink style package management. After the - installation, a package archive is created using the installed files. - This archive is then used to install the package either on the local - machine or can even be used to install the package on other machines.</para> - - <para>This approach is used by most of the package managers found in the - commercial distributions. Examples of package managers that follow this - approach are RPM (which, incidentally, is required by the <ulink - url="http://refspecs.linuxfoundation.org/lsb.shtml">Linux - Standard Base Specification</ulink>), pkg-utils, Debian's apt, and - Gentoo's Portage system. A hint describing how to adopt this style of - package management for LFS systems is located at <ulink - url="&hints-root;fakeroot.txt"/>.</para> - - <para>Creation of package files that include dependency information is - complex and is beyond the scope of LFS.</para> - - <para>Slackware uses a <command>tar</command> based system for package - archives. This system purposely does not handle package dependencies - as more complex package managers do. For details of Slackware package - management, see <ulink - url="http://www.slackbook.org/html/package-management.html"/>.</para> - </sect3> - - <sect3> - <title>User Based Management</title> - - <para>This scheme, unique to LFS, was devised by Matthias Benkmann, and is - available from the <ulink url="&hints-index;">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 - too complex to describe in this section. For the details please see the - hint at <ulink url="&hints-root;more_control_and_pkg_man.txt"/>.</para> - - </sect3> - - </sect2> - - <sect2> - <title>Deploying LFS on Multiple Systems</title> - - <para>One of the advantages of an LFS system is that there are no files that - depend on the position of files on a disk system. Cloning an LFS build to - another computer with the same architecture as the base system is as - simple as using <command>tar</command> on the LFS partition that contains - the root directory (about 250MB uncompressed for a base LFS build), copying - that file via network transfer or CD-ROM to the new system and expanding - it. From that point, a few configuration files will have to be changed. - Configuration files that may need to be updated include: - <filename>/etc/hosts</filename>, - <filename>/etc/fstab</filename>, - <filename>/etc/passwd</filename>, - <filename>/etc/group</filename>, - <phrase revision="systemd"> - <filename>/etc/shadow</filename>, and - <filename>/etc/ld.so.conf</filename>. - </phrase> - <phrase revision="sysv"> - <filename>/etc/shadow</filename>, - <filename>/etc/ld.so.conf</filename>, - <filename>/etc/sysconfig/rc.site</filename>, - <filename>/etc/sysconfig/network</filename>, and - <filename>/etc/sysconfig/ifconfig.eth0</filename>. - </phrase> - </para> - - <para>A custom kernel may need to be built for the new system depending on - differences in system hardware and the original kernel - configuration.</para> - - <note><para>There have been some reports of issues when copying between - similar but not identical architectures. For instance, the instruction set - for an Intel system is not identical with an AMD processor and later - versions of some processors may have instructions that are unavailable in - earlier versions.</para></note> - - <para>Finally the new system has to be made bootable via <xref - linkend="ch-bootable-grub"/>.</para> - - </sect2> - -</sect1> |