[4122007] | 1 | <?xml version="1.0" encoding="ISO-8859-1"?>
|
---|
| 2 | <!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
|
---|
| 3 | "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
|
---|
| 4 | <!ENTITY % general-entities SYSTEM "../../general.ent">
|
---|
| 5 | %general-entities;
|
---|
| 6 | ]>
|
---|
| 7 |
|
---|
[3d760b6] | 8 | <sect1 id="intro-important-pkgmgt">
|
---|
[71e06e23] | 9 | <?dbhtml filename="pkgmgt.html"?>
|
---|
[3d760b6] | 10 | <title>Package Management</title>
|
---|
| 11 |
|
---|
[511570b] | 12 | <para>Package Management is an often requested addition
|
---|
[3d760b6] | 13 | to the <acronym>LFS</acronym> Book. A Package Manager allows tracking
|
---|
| 14 | the installation of files making it easy to remove and upgrade packages.
|
---|
| 15 | And before you begin to wonder, NO - this section does not talk about any
|
---|
| 16 | particular package manager, nor does it recommend one. What it provides is
|
---|
| 17 | a roundup of the more popular techniques and how they work. The perfect
|
---|
| 18 | package manager for you may be among these techniques or may be a combination
|
---|
[511570b] | 19 | of two or more of these techniques. This section briefly mentions
|
---|
| 20 | issues that may arise when upgrading packages.</para>
|
---|
[3d760b6] | 21 |
|
---|
| 22 | <para>Some reasons why no package manager is mentioned in <acronym>LFS</acronym>
|
---|
| 23 | or <acronym>BLFS</acronym>:</para>
|
---|
| 24 |
|
---|
| 25 | <itemizedlist>
|
---|
| 26 | <listitem><para>Dealing with package management takes the focus away from
|
---|
| 27 | the goals of these books - Teaching how a Linux System is built.</para></listitem>
|
---|
| 28 | <listitem><para>There are multiple solutions for package management, each having
|
---|
[1f629e3] | 29 | its strengths and drawbacks. Including one that satifies all audiences is
|
---|
| 30 | difficult.</para></listitem>
|
---|
[3d760b6] | 31 | </itemizedlist>
|
---|
| 32 |
|
---|
| 33 | <para>There are some hints written on the topic of package management. Visit
|
---|
| 34 | the <ulink url="http://www.linuxfromscratch.org/hints/">Hints subproject</ulink>
|
---|
| 35 | to find if one of them fits your need.</para>
|
---|
| 36 |
|
---|
| 37 |
|
---|
| 38 | <sect2>
|
---|
| 39 | <title>Upgrade Issues</title>
|
---|
| 40 |
|
---|
[1f629e3] | 41 | <para>A Package Manager makes it easy to upgrade to newer versions as and when they
|
---|
| 42 | are released. Generally the instructions in the <acronym>LFS</acronym> and
|
---|
| 43 | <acronym>BLFS</acronym> Book can be used to upgrade to the newer versions.
|
---|
| 44 | Following are some points that you should be aware of when upgrading
|
---|
[511570b] | 45 | packages, especially on a running system.</para>
|
---|
[3d760b6] | 46 |
|
---|
| 47 | <itemizedlist>
|
---|
| 48 | <listitem><para>It is recommended that if one of the toolchain package (glibc, gcc,
|
---|
| 49 | binutils) needs to be upgraded to a newer minor vesion, it is safer to rebuild
|
---|
[511570b] | 50 | <acronym>LFS</acronym>. Though you <emphasis>may</emphasis> be able to get by
|
---|
[3d760b6] | 51 | rebuilding all the packages in their dependency order. We do not recommend the
|
---|
[511570b] | 52 | latter. For example, if glibc-2.2.x needs to be updated to glibc-2.3.x, it is safer
|
---|
[3d760b6] | 53 | to rebuild. For micro version updates, a simple reinstallation usually works, but
|
---|
| 54 | is not guaranteed. For example, upgrading from glibc-2.3.1 to glibc-2.3.2 will not
|
---|
| 55 | usually cause any problems.</para></listitem>
|
---|
| 56 | <listitem><para>If a package containing a shared library is updated, and if the
|
---|
| 57 | soname of the library changes, then all the packages dynamically linked to the
|
---|
| 58 | library need to be recompiled to link against the newer library. (Note that there
|
---|
| 59 | is no corelation between the package version and the soname of the library.) For
|
---|
| 60 | example, consider a package foo-1.2.3 that installs a shared library with soname
|
---|
| 61 | <filename>libfoo.so.1</filename>. Say you upgrade the package to a newer version
|
---|
| 62 | foo-1.2.4 that installs a shared library with soname <filename>libfoo.so.2</filename>.
|
---|
| 63 | In this case, all packages that are dynamically linked to <filename>libfoo.so.1</filename>
|
---|
| 64 | need to be recompiled to link against <filename>libfoo.so.2</filename>. Note that
|
---|
| 65 | you should not remove the previous libraries till the dependent packages are
|
---|
| 66 | recompiled.</para></listitem>
|
---|
| 67 | <listitem><para>If you are upgrading a running system, be on the lookout for
|
---|
| 68 | packages that use <command>cp</command> instead of <command>install</command> to
|
---|
| 69 | install files. The latter command is usually safer if the executable or library
|
---|
| 70 | is already loaded in memory.</para></listitem>
|
---|
| 71 | </itemizedlist>
|
---|
| 72 |
|
---|
| 73 | </sect2>
|
---|
| 74 |
|
---|
| 75 |
|
---|
| 76 | <sect2>
|
---|
| 77 | <title>Package Management Techniques</title>
|
---|
| 78 |
|
---|
[1f629e3] | 79 | <para>The following are some common package management techniques. Before
|
---|
| 80 | making a decision on a package manager, do a research on the various
|
---|
| 81 | techniques, particularly the drawbacks of the particular scheme.</para>
|
---|
[3d760b6] | 82 |
|
---|
| 83 | <sect3>
|
---|
[511570b] | 84 | <title>It is all in my head!</title>
|
---|
[3d760b6] | 85 |
|
---|
| 86 | <para>Yes, this is a package management technique. Some folks do not find the
|
---|
| 87 | need for a package manager because they know the packages intimately and know
|
---|
| 88 | what files are installed by each package. Some users also do not need any
|
---|
| 89 | package management because they plan on rebuilding the entire <acronym>LFS</acronym>
|
---|
| 90 | when a package is changed.</para>
|
---|
| 91 |
|
---|
| 92 | </sect3>
|
---|
| 93 |
|
---|
| 94 | <sect3>
|
---|
[1f629e3] | 95 | <title>Install in separate directories</title>
|
---|
[3d760b6] | 96 |
|
---|
| 97 | <para>This is a simplistic package management that does not need any extra package
|
---|
[1f629e3] | 98 | to manage the installations. Each package is installed in a separate directory.
|
---|
[3d760b6] | 99 | For example, package foo-1.1 is installed in <filename>/usr/pkg/foo-1.1</filename>
|
---|
| 100 | and a symlink is made from <filename>/usr/pkg/foo</filename> to
|
---|
| 101 | <filename>/usr/pkg/foo-1.1</filename>. When installing a new version foo-1.2,
|
---|
| 102 | it is installed in <filename>/usr/pkg/foo-1.2</filename> and the previous
|
---|
| 103 | symlink is replaced by a symlink to the new vesion.</para>
|
---|
| 104 |
|
---|
| 105 | <para>The environment variables such as those
|
---|
[b5ea3492] | 106 | mentioned in <xref linkend="intro-important-beyond"/> need to be expanded to
|
---|
[3d760b6] | 107 | include <filename>/usr/pkg/foo</filename>. For more than a few packages,
|
---|
[aa15d3e] | 108 | this scheme becomes unmanageable.</para>
|
---|
[3d760b6] | 109 |
|
---|
| 110 | </sect3>
|
---|
| 111 |
|
---|
| 112 | <sect3>
|
---|
| 113 | <title>Symlink style package management</title>
|
---|
| 114 |
|
---|
| 115 | <para>This is a variation of the previous package management technique. Each package
|
---|
| 116 | is installed similar to the previous scheme. But instead of making the symlink,
|
---|
| 117 | each file is symlinked into <filename>/usr</filename> hierarchy. This removes the need
|
---|
| 118 | to expand the environment variables. Though the symlinks can be created by the user,
|
---|
| 119 | to automate the creation, many package managers have been written on this approach.
|
---|
[aa15d3e] | 120 | A few of the popular ones are Stow, Epkg, Graft, and Depot.</para>
|
---|
[3d760b6] | 121 |
|
---|
| 122 | <para>The installation needs to be faked, so that the package thinks that it is
|
---|
[aa15d3e] | 123 | installed in <filename class="directory">/usr</filename> though in reality it is installed in
|
---|
| 124 | <filename class="directory">/usr/pkg</filename> hierarchy. Installing in this manner is not usually a trivial
|
---|
[3d760b6] | 125 | task. For example, consider that you are installing a package libfoo-1.1. The following
|
---|
| 126 | instructions may not install the package properly:</para>
|
---|
| 127 |
|
---|
| 128 | <screen><userinput><command>./configure --prefix=/usr/pkg/libfoo/1.1 &&
|
---|
| 129 | make &&
|
---|
| 130 | make install</command></userinput></screen>
|
---|
| 131 |
|
---|
| 132 | <para>The installation will work, but the dependent packages may not link to
|
---|
| 133 | libfoo as you would expect. If you compile a package that links against libfoo,
|
---|
| 134 | you may notice that it is linked to <filename>/usr/pkg/libfoo/1.1/lib/libfoo.so.1</filename>
|
---|
| 135 | instead of <filename>/usr/lib/libfoo.so.1</filename> as you would expect. The correct
|
---|
| 136 | approach is to use <envar>DESTDIR</envar> strategy to fake installation of the package.
|
---|
| 137 | This approach works as follows:</para>
|
---|
| 138 |
|
---|
| 139 | <screen><userinput><command>./configure --prefix=/usr &&
|
---|
| 140 | make &&
|
---|
| 141 | make DESTDIR=/usr/pkg/libfoo/1.1 install</command></userinput></screen>
|
---|
| 142 |
|
---|
| 143 | <para>Most of the packages do support this approach, but there are some which do not.
|
---|
| 144 | For the non-compliant packages, you may either need to manually install the package,
|
---|
| 145 | or you may find that it is easier to install some problematic packages into
|
---|
| 146 | <filename>/opt</filename>.</para>
|
---|
| 147 |
|
---|
| 148 | </sect3>
|
---|
| 149 |
|
---|
| 150 | <sect3>
|
---|
| 151 | <title>Timestamp based</title>
|
---|
| 152 |
|
---|
| 153 | <para>In this technique, a file is timestamped before the installation of the package.
|
---|
| 154 | After the installation, a simple use of the <command>find</command> command with the
|
---|
| 155 | appropriate options can generate a log of all the files installed after the timestamp
|
---|
| 156 | file was created. A package manager written with this approach is install-log.</para>
|
---|
| 157 |
|
---|
| 158 | <para>Though this scheme has the advantage of being simple, it has two drawbacks.
|
---|
| 159 | If during installation, the files are installed with any timestamp other than the
|
---|
| 160 | current time, those files will not be tracked by the package manager. Also, this
|
---|
| 161 | scheme can only be used when one package is installed at a time. The logs are not
|
---|
| 162 | reliable if two packages are being installed on two different consoles.</para>
|
---|
| 163 |
|
---|
| 164 | </sect3>
|
---|
| 165 |
|
---|
| 166 | <sect3>
|
---|
| 167 | <title>LD_PRELOAD based</title>
|
---|
| 168 |
|
---|
[511570b] | 169 | <para>In this approach, a library is preloaded before installation. During
|
---|
[3d760b6] | 170 | installation, this library tracks the packages that are being installed by
|
---|
| 171 | attaching itself to various executables such as <command>cp</command>,
|
---|
| 172 | <command>install</command>, <command>mv</command> and tracking the system
|
---|
| 173 | calls that modify the filesystem. For this approach to work, all the executables
|
---|
| 174 | need to be dymanically linked without the suid or sgid bit. Preloading the
|
---|
[1f629e3] | 175 | library may cause some unwanted side-effects during installation; hence
|
---|
| 176 | do perform some tests to ensure that the package manager does not break
|
---|
| 177 | anything and logs all the appropriate files.</para>
|
---|
[3d760b6] | 178 |
|
---|
| 179 | </sect3>
|
---|
| 180 |
|
---|
| 181 | <sect3>
|
---|
| 182 | <title>Creating Package Archives</title>
|
---|
| 183 |
|
---|
[1f629e3] | 184 | <para>In this scheme, the package installation is faked into a separate
|
---|
[3d760b6] | 185 | tree as described in the Symlink style package management. After the
|
---|
| 186 | installation, a package archive is created using the installed files.
|
---|
| 187 | This archive is then used to install the package either on the local
|
---|
| 188 | machine or can even be used to install the package on other machines.</para>
|
---|
| 189 |
|
---|
| 190 | <para>This approach is used by most of the package managers found in the
|
---|
| 191 | commercial distributions. Examples of package Managers that follow this
|
---|
| 192 | approach are RPM, pkg-utils, Debian's apt, Gentoo's Portage system.</para>
|
---|
| 193 |
|
---|
| 194 | </sect3>
|
---|
| 195 |
|
---|
| 196 | <sect3>
|
---|
| 197 | <title>User Based Management</title>
|
---|
| 198 |
|
---|
| 199 | <para>This scheme, that is unique to <acronym>LFS</acronym>, was
|
---|
| 200 | devised by Matthias Benkmann, and is available from the <ulink
|
---|
| 201 | url="http://www.linuxfromscratch.org/hints/">Hints Project</ulink>.
|
---|
[1f629e3] | 202 | In this scheme, each package is installed as a separate user into
|
---|
[3d760b6] | 203 | the standard locations. Files belonging to a package are easily
|
---|
| 204 | identified by checking the user id. The features and shortcomings
|
---|
| 205 | of this approach are too complex to describe in this section. For
|
---|
| 206 | the details please see the hint at <ulink
|
---|
| 207 | url="http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt"/>.</para>
|
---|
| 208 |
|
---|
| 209 | </sect3>
|
---|
| 210 |
|
---|
| 211 | </sect2>
|
---|
| 212 |
|
---|
| 213 |
|
---|
| 214 | </sect1>
|
---|