source: chapter06/pkgmgt.xml@ 1118b17

10.0 10.0-rc1 10.1 10.1-rc1 11.0 11.0-rc1 11.0-rc2 11.0-rc3 7.10 7.10-rc1 8.0 8.0-rc1 8.1 8.1-rc1 8.1-rc2 8.2 8.2-rc1 8.3 8.3-rc1 8.3-rc2 8.4 8.4-rc1 9.0 9.0-rc1 9.1 9.1-rc1 cross-chap5 ml-11.0 multilib nosym old-trunk trunk xry111/git-transition xry111/glibc-2.34 xry111/tester-nohack xry111/usr-move
Last change on this file since 1118b17 was 1118b17, checked in by Bruce Dubbs <bdubbs@…>, 6 years ago

Create branches/merge in svn repo fo rtesting of merged LFS books

git-svn-id: http://svn.linuxfromscratch.org/LFS/branches/merge@11073 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689

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