[1fa2099] | 1 | <?xml version="1.0" encoding="ISO-8859-1"?>
|
---|
| 2 | <!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
---|
| 3 | "http://www.oasis-open.org/docbook/xml/4.5/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. As well as the binary and library files, a
|
---|
| 16 | package manager will handle the installation of configuration files. Before
|
---|
| 17 | you begin to wonder, NO—this section will not talk about nor recommend
|
---|
| 18 | any particular package manager. What it provides is a roundup of the more
|
---|
| 19 | popular techniques and how they work. The perfect package manager for you may
|
---|
| 20 | be among these techniques or may be a combination of two or more of these
|
---|
| 21 | techniques. This section briefly mentions issues that may arise when upgrading
|
---|
| 22 | packages.</para>
|
---|
| 23 |
|
---|
| 24 | <para>Some reasons why no package manager is mentioned in LFS or BLFS
|
---|
| 25 | include:</para>
|
---|
| 26 |
|
---|
| 27 | <itemizedlist>
|
---|
| 28 | <listitem>
|
---|
| 29 | <para>Dealing with package management takes the focus away from the goals
|
---|
| 30 | of these books—teaching how a Linux system is built.</para>
|
---|
| 31 | </listitem>
|
---|
| 32 |
|
---|
| 33 | <listitem>
|
---|
| 34 | <para>There are multiple solutions for package management, each having
|
---|
| 35 | its strengths and drawbacks. Including one that satisfies all audiences
|
---|
| 36 | is difficult.</para>
|
---|
| 37 | </listitem>
|
---|
| 38 | </itemizedlist>
|
---|
| 39 |
|
---|
| 40 | <para>There are some hints written on the topic of package management. Visit
|
---|
[9f715a8] | 41 | the <ulink url="&hints-root;">Hints Project</ulink> and see if one of them
|
---|
[1fa2099] | 42 | fits your need.</para>
|
---|
| 43 |
|
---|
| 44 | <sect2>
|
---|
| 45 | <title>Upgrade Issues</title>
|
---|
| 46 |
|
---|
| 47 | <para>A Package Manager makes it easy to upgrade to newer versions when they
|
---|
[37e35d2] | 48 | are released. Generally the instructions in the LFS and BLFS books can be
|
---|
[1fa2099] | 49 | used to upgrade to the newer versions. Here are some points that you should
|
---|
| 50 | be aware of when upgrading packages, especially on a running system.</para>
|
---|
| 51 |
|
---|
| 52 | <itemizedlist>
|
---|
| 53 | <listitem>
|
---|
| 54 | <para>If Glibc needs to be upgraded to a newer version, (e.g. from
|
---|
[37e35d2] | 55 | glibc-2.31 to glibc-2.32), it is safer to rebuild LFS. Though you
|
---|
[1fa2099] | 56 | <emphasis>may</emphasis> be able to rebuild all the packages in their
|
---|
| 57 | dependency order, we do not recommend it. </para>
|
---|
| 58 | </listitem>
|
---|
| 59 |
|
---|
[37e35d2] | 60 | <listitem> <para>If a package containing a shared library is updated, and
|
---|
| 61 | if the name of the library changes, then any the packages dynamically
|
---|
| 62 | linked to the library need to be recompiled in order to link against the
|
---|
| 63 | newer library. (Note that there is no correlation between the package
|
---|
| 64 | version and the name of the library.) For example, consider a package
|
---|
| 65 | foo-1.2.3 that installs a shared library with name <filename
|
---|
| 66 | class='libraryfile'>libfoo.so.1</filename>. If you upgrade the package to
|
---|
| 67 | a newer version foo-1.2.4 that installs a shared library with name
|
---|
| 68 | <filename class='libraryfile'>libfoo.so.2</filename>. In this case, any
|
---|
| 69 | packages that are dynamically linked to <filename
|
---|
| 70 | class='libraryfile'>libfoo.so.1</filename> need to be recompiled to link
|
---|
| 71 | against <filename class='libraryfile'>libfoo.so.2</filename> in order to
|
---|
| 72 | use the new library version. You should not remove the previous
|
---|
| 73 | libraries unless all the dependent packages are recompiled.</para>
|
---|
| 74 | </listitem> </itemizedlist>
|
---|
[1fa2099] | 75 |
|
---|
| 76 | </sect2>
|
---|
| 77 |
|
---|
| 78 | <sect2>
|
---|
| 79 | <title>Package Management Techniques</title>
|
---|
| 80 |
|
---|
| 81 | <para>The following are some common package management techniques. Before
|
---|
| 82 | making a decision on a package manager, do some research on the various
|
---|
| 83 | techniques, particularly the drawbacks of the particular scheme.</para>
|
---|
| 84 |
|
---|
| 85 | <sect3>
|
---|
| 86 | <title>It is All in My Head!</title>
|
---|
| 87 |
|
---|
| 88 | <para>Yes, this is a package management technique. Some folks do not find
|
---|
| 89 | the need for a package manager because they know the packages intimately
|
---|
| 90 | and know what files are installed by each package. Some users also do not
|
---|
| 91 | need any package management because they plan on rebuilding the entire
|
---|
| 92 | system when a package is changed.</para>
|
---|
| 93 |
|
---|
| 94 | </sect3>
|
---|
| 95 |
|
---|
| 96 | <sect3>
|
---|
| 97 | <title>Install in Separate Directories</title>
|
---|
| 98 |
|
---|
| 99 | <para>This is a simplistic package management that does not need any extra
|
---|
| 100 | package to manage the installations. Each package is installed in a
|
---|
| 101 | separate directory. For example, package foo-1.1 is installed in
|
---|
| 102 | <filename class='directory'>/usr/pkg/foo-1.1</filename>
|
---|
| 103 | and a symlink is made from <filename>/usr/pkg/foo</filename> to
|
---|
| 104 | <filename class='directory'>/usr/pkg/foo-1.1</filename>. When installing
|
---|
| 105 | a new version foo-1.2, it is installed in
|
---|
| 106 | <filename class='directory'>/usr/pkg/foo-1.2</filename> and the previous
|
---|
| 107 | symlink is replaced by a symlink to the new version.</para>
|
---|
| 108 |
|
---|
| 109 | <para>Environment variables such as <envar>PATH</envar>,
|
---|
| 110 | <envar>LD_LIBRARY_PATH</envar>, <envar>MANPATH</envar>,
|
---|
| 111 | <envar>INFOPATH</envar> and <envar>CPPFLAGS</envar> need to be expanded to
|
---|
| 112 | include <filename>/usr/pkg/foo</filename>. For more than a few packages,
|
---|
| 113 | this scheme becomes unmanageable.</para>
|
---|
| 114 |
|
---|
| 115 | </sect3>
|
---|
| 116 |
|
---|
| 117 | <sect3>
|
---|
| 118 | <title>Symlink Style Package Management</title>
|
---|
| 119 |
|
---|
| 120 | <para>This is a variation of the previous package management technique.
|
---|
| 121 | Each package is installed similar to the previous scheme. But instead of
|
---|
| 122 | making the symlink, each file is symlinked into the
|
---|
| 123 | <filename class='directory'>/usr</filename> hierarchy. This removes the
|
---|
| 124 | need to expand the environment variables. Though the symlinks can be
|
---|
| 125 | created by the user to automate the creation, many package managers have
|
---|
| 126 | been written using this approach. A few of the popular ones include Stow,
|
---|
| 127 | Epkg, Graft, and Depot.</para>
|
---|
| 128 |
|
---|
| 129 | <para>The installation needs to be faked, so that the package thinks that
|
---|
| 130 | it is installed in <filename class="directory">/usr</filename> though in
|
---|
| 131 | reality it is installed in the
|
---|
| 132 | <filename class="directory">/usr/pkg</filename> hierarchy. Installing in
|
---|
| 133 | this manner is not usually a trivial task. For example, consider that you
|
---|
| 134 | are installing a package libfoo-1.1. The following instructions may
|
---|
| 135 | not install the package properly:</para>
|
---|
| 136 |
|
---|
| 137 | <screen role="nodump"><userinput>./configure --prefix=/usr/pkg/libfoo/1.1
|
---|
| 138 | make
|
---|
| 139 | make install</userinput></screen>
|
---|
| 140 |
|
---|
| 141 | <para>The installation will work, but the dependent packages may not link
|
---|
| 142 | to libfoo as you would expect. If you compile a package that links against
|
---|
| 143 | libfoo, you may notice that it is linked to
|
---|
| 144 | <filename class='libraryfile'>/usr/pkg/libfoo/1.1/lib/libfoo.so.1</filename>
|
---|
| 145 | instead of <filename class='libraryfile'>/usr/lib/libfoo.so.1</filename>
|
---|
| 146 | as you would expect. The correct approach is to use the
|
---|
| 147 | <envar>DESTDIR</envar> strategy to fake installation of the package. This
|
---|
| 148 | approach works as follows:</para>
|
---|
| 149 |
|
---|
| 150 | <screen role="nodump"><userinput>./configure --prefix=/usr
|
---|
| 151 | make
|
---|
| 152 | make DESTDIR=/usr/pkg/libfoo/1.1 install</userinput></screen>
|
---|
| 153 |
|
---|
| 154 | <para>Most packages support this approach, but there are some which do not.
|
---|
| 155 | For the non-compliant packages, you may either need to manually install the
|
---|
| 156 | package, or you may find that it is easier to install some problematic
|
---|
| 157 | packages into <filename class='directory'>/opt</filename>.</para>
|
---|
| 158 |
|
---|
| 159 | </sect3>
|
---|
| 160 |
|
---|
| 161 | <sect3>
|
---|
| 162 | <title>Timestamp Based</title>
|
---|
| 163 |
|
---|
| 164 | <para>In this technique, a file is timestamped before the installation of
|
---|
| 165 | the package. After the installation, a simple use of the
|
---|
| 166 | <command>find</command> command with the appropriate options can generate
|
---|
| 167 | a log of all the files installed after the timestamp file was created. A
|
---|
| 168 | package manager written with this approach is install-log.</para>
|
---|
| 169 |
|
---|
| 170 | <para>Though this scheme has the advantage of being simple, it has two
|
---|
| 171 | drawbacks. If, during installation, the files are installed with any
|
---|
| 172 | timestamp other than the current time, those files will not be tracked by
|
---|
| 173 | the package manager. Also, this scheme can only be used when one package
|
---|
| 174 | is installed at a time. The logs are not reliable if two packages are
|
---|
| 175 | being installed on two different consoles.</para>
|
---|
| 176 |
|
---|
| 177 | </sect3>
|
---|
| 178 |
|
---|
| 179 | <sect3>
|
---|
| 180 | <title>Tracing Installation Scripts</title>
|
---|
| 181 |
|
---|
| 182 | <para>In this approach, the commands that the installation scripts perform
|
---|
| 183 | are recorded. There are two techniques that one can use:</para>
|
---|
| 184 |
|
---|
| 185 | <para>The <envar>LD_PRELOAD</envar> environment variable can be set to
|
---|
| 186 | point to a library to be preloaded before installation. During
|
---|
| 187 | installation, this library tracks the packages that are being installed by
|
---|
| 188 | attaching itself to various executables such as <command>cp</command>,
|
---|
| 189 | <command>install</command>, <command>mv</command> and tracking the system
|
---|
| 190 | calls that modify the filesystem. For this approach to work, all the
|
---|
| 191 | executables need to be dynamically linked without the suid or sgid bit.
|
---|
| 192 | Preloading the library may cause some unwanted side-effects during
|
---|
| 193 | installation. Therefore, it is advised that one performs some tests to
|
---|
| 194 | ensure that the package manager does not break anything and logs all the
|
---|
| 195 | appropriate files.</para>
|
---|
| 196 |
|
---|
| 197 | <para>The second technique is to use <command>strace</command>, which
|
---|
| 198 | logs all system calls made during the execution of the installation
|
---|
| 199 | scripts.</para>
|
---|
| 200 | </sect3>
|
---|
| 201 |
|
---|
| 202 | <sect3>
|
---|
| 203 | <title>Creating Package Archives</title>
|
---|
| 204 |
|
---|
| 205 | <para>In this scheme, the package installation is faked into a separate
|
---|
| 206 | tree as described in the Symlink style package management. After the
|
---|
| 207 | installation, a package archive is created using the installed files.
|
---|
| 208 | This archive is then used to install the package either on the local
|
---|
| 209 | machine or can even be used to install the package on other machines.</para>
|
---|
| 210 |
|
---|
| 211 | <para>This approach is used by most of the package managers found in the
|
---|
| 212 | commercial distributions. Examples of package managers that follow this
|
---|
| 213 | approach are RPM (which, incidentally, is required by the <ulink
|
---|
| 214 | url="http://refspecs.linuxfoundation.org/lsb.shtml">Linux
|
---|
| 215 | Standard Base Specification</ulink>), pkg-utils, Debian's apt, and
|
---|
| 216 | Gentoo's Portage system. A hint describing how to adopt this style of
|
---|
| 217 | package management for LFS systems is located at <ulink
|
---|
| 218 | url="&hints-root;fakeroot.txt"/>.</para>
|
---|
| 219 |
|
---|
| 220 | <para>Creation of package files that include dependency information is
|
---|
| 221 | complex and is beyond the scope of LFS.</para>
|
---|
| 222 |
|
---|
| 223 | <para>Slackware uses a <command>tar</command> based system for package
|
---|
| 224 | archives. This system purposely does not handle package dependencies
|
---|
| 225 | as more complex package managers do. For details of Slackware package
|
---|
| 226 | management, see <ulink
|
---|
| 227 | url="http://www.slackbook.org/html/package-management.html"/>.</para>
|
---|
| 228 | </sect3>
|
---|
| 229 |
|
---|
| 230 | <sect3>
|
---|
| 231 | <title>User Based Management</title>
|
---|
| 232 |
|
---|
| 233 | <para>This scheme, unique to LFS, was devised by Matthias Benkmann, and is
|
---|
[9f715a8] | 234 | available from the <ulink url="&hints-root;">Hints Project</ulink>. In
|
---|
[1fa2099] | 235 | this scheme, each package is installed as a separate user into the
|
---|
| 236 | standard locations. Files belonging to a package are easily identified by
|
---|
| 237 | checking the user ID. The features and shortcomings of this approach are
|
---|
| 238 | too complex to describe in this section. For the details please see the
|
---|
| 239 | hint at <ulink url="&hints-root;more_control_and_pkg_man.txt"/>.</para>
|
---|
| 240 |
|
---|
| 241 | </sect3>
|
---|
| 242 |
|
---|
| 243 | </sect2>
|
---|
| 244 |
|
---|
| 245 | <sect2>
|
---|
| 246 | <title>Deploying LFS on Multiple Systems</title>
|
---|
| 247 |
|
---|
| 248 | <para>One of the advantages of an LFS system is that there are no files that
|
---|
| 249 | depend on the position of files on a disk system. Cloning an LFS build to
|
---|
| 250 | another computer with the same architecture as the base system is as
|
---|
| 251 | simple as using <command>tar</command> on the LFS partition that contains
|
---|
| 252 | the root directory (about 250MB uncompressed for a base LFS build), copying
|
---|
| 253 | that file via network transfer or CD-ROM to the new system and expanding
|
---|
| 254 | it. From that point, a few configuration files will have to be changed.
|
---|
| 255 | Configuration files that may need to be updated include:
|
---|
| 256 | <filename>/etc/hosts</filename>,
|
---|
| 257 | <filename>/etc/fstab</filename>,
|
---|
| 258 | <filename>/etc/passwd</filename>,
|
---|
| 259 | <filename>/etc/group</filename>,
|
---|
| 260 | <phrase revision="systemd">
|
---|
| 261 | <filename>/etc/shadow</filename>, and
|
---|
| 262 | <filename>/etc/ld.so.conf</filename>.
|
---|
| 263 | </phrase>
|
---|
| 264 | <phrase revision="sysv">
|
---|
| 265 | <filename>/etc/shadow</filename>,
|
---|
| 266 | <filename>/etc/ld.so.conf</filename>,
|
---|
| 267 | <filename>/etc/sysconfig/rc.site</filename>,
|
---|
| 268 | <filename>/etc/sysconfig/network</filename>, and
|
---|
| 269 | <filename>/etc/sysconfig/ifconfig.eth0</filename>.
|
---|
| 270 | </phrase>
|
---|
| 271 | </para>
|
---|
| 272 |
|
---|
| 273 | <para>A custom kernel may need to be built for the new system depending on
|
---|
| 274 | differences in system hardware and the original kernel
|
---|
| 275 | configuration.</para>
|
---|
| 276 |
|
---|
| 277 | <note><para>There have been some reports of issues when copying between
|
---|
| 278 | similar but not identical architectures. For instance, the instruction set
|
---|
| 279 | for an Intel system is not identical with an AMD processor and later
|
---|
| 280 | versions of some processors may have instructions that are unavailable in
|
---|
| 281 | earlier versions.</para></note>
|
---|
| 282 |
|
---|
| 283 | <para>Finally the new system has to be made bootable via <xref
|
---|
| 284 | linkend="ch-bootable-grub"/>.</para>
|
---|
| 285 |
|
---|
| 286 | </sect2>
|
---|
| 287 |
|
---|
| 288 | </sect1>
|
---|