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