source: chapter08/pkgmgt.xml@ de28837

11.0 11.0-rc1 11.0-rc2 11.0-rc3 11.1 11.1-rc1 arm ml-11.0 multilib s6-init trunk xry111/clfs-ng xry111/glibc-2.34 xry111/lfs-next
Last change on this file since de28837 was de28837, checked in by Xi Ruoyao <xry111@…>, 13 months ago

Hopefully, complete strip workaround

In stripping, /usr/bin/bash, /usr/bin/find, and /usr/bin/strip are
running. Strip them, and all libraries used by them in /tmp, then
install them back.

We can't use this for all libraries or binaries: the process above
discouples hard links (for example /usr/bin/perl and perl5.34.0). So
unfortunately the stripping instruction is now a stupidly long bash
script...

  • Property mode set to 100644
File size: 16.9 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-root;">Hints Project</ulink> and see if one of them
42 fits your need.</para>
43
44 <sect2 id='pkgmgmt-upgrade-issues'>
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 books 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 Linux kernel needs to be upgraded (for example, from
55 5.10.17 to 5.10.18 or 5.11.1), nothing else need to be rebuilt.
56 The system will keep working fine thanks to the well-defined border
57 between kernel and userspace. Specifically, Linux API headers
58 need not to be (and should not be, see the next item) upgraded
59 alongside the kernel. You'll need to reboot your system to use the
60 upgraded kernel.</para>
61 </listitem>
62
63 <listitem>
64 <para>If Linux API headers or Glibc needs to be upgraded to a newer
65 version, (e.g. from glibc-2.31 to glibc-2.32), it is safer to
66 rebuild LFS. Though you <emphasis>may</emphasis> be able to rebuild
67 all the packages in their dependency order, we do not recommend
68 it. </para>
69 </listitem>
70
71 <listitem> <para>If a package containing a shared library is updated, and
72 if the name of the library changes, then any the packages dynamically
73 linked to the library need to be recompiled in order to link against the
74 newer library. (Note that there is no correlation between the package
75 version and the name of the library.) For example, consider a package
76 foo-1.2.3 that installs a shared library with name <filename
77 class='libraryfile'>libfoo.so.1</filename>. If you upgrade the package to
78 a newer version foo-1.2.4 that installs a shared library with name
79 <filename class='libraryfile'>libfoo.so.2</filename>. In this case, any
80 packages that are dynamically linked to <filename
81 class='libraryfile'>libfoo.so.1</filename> need to be recompiled to link
82 against <filename class='libraryfile'>libfoo.so.2</filename> in order to
83 use the new library version. You should not remove the previous
84 libraries unless all the dependent packages are recompiled.</para>
85 </listitem>
86
87 <listitem> <para>If a package containing a shared library is updated,
88 and the name of library doesn't change, but the version number of the
89 library <emphasis role="bold">file</emphasis> decreases (for example,
90 the name of the library is kept named
91 <filename class='libraryfile'>libfoo.so.1</filename>,
92 but the name of library file is changed from
93 <filename class='libraryfile'>libfoo.so.1.25</filename> to
94 <filename class='libraryfile'>libfoo.so.1.24</filename>),
95 you should remove the library file from the previously installed version
96 (<filename class='libraryfile'>libfoo.so.1.25</filename> in the case).
97 Or, a <command>ldconfig</command> run (by yourself using a command
98 line, or by the installation of some package) will reset the symlink
99 <filename class='libraryfile'>libfoo.so.1</filename> to point to
100 the old library file because it seems having a <quote>newer</quote>
101 version, as its version number is larger. This situation may happen if
102 you have to downgrade a package, or the package changes the versioning
103 scheme of library files suddenly.</para> </listitem>
104
105 <listitem> <para>If a package containing a shared library is updated,
106 and the name of library doesn't change, but a severe issue
107 (especially, a security vulnerability) is fixed, all running programs
108 linked to the shared library should be restarted. The following
109 command, run as <systemitem class="username">root</systemitem> after
110 updating, will list what is using the old versions of those libraries
111 (replace <replaceable>libfoo</replaceable> with the name of the
112 library):</para>
113
114<screen><userinput role="nodump">grep -l -e '<replaceable>libfoo</replaceable>.*deleted' /proc/*/maps |
115 tr -cd 0-9\\n | xargs -r ps u</userinput></screen>
116
117 <para>
118 If <application>OpenSSH</application> is being used for accessing
119 the system and it is linked to the updated library, you need to
120 restart <command>sshd</command> service, then logout, login again,
121 and rerun that command to confirm nothing is still using the
122 deleted libraries.
123 </para></listitem>
124
125 <listitem>
126 <para>If a binary or a shared library is overwrote, the processes
127 using the code or data in the binary or library may crash. The
128 correct way to update a binary or a shared library without causing
129 the process to crash is: remove it first, then install the new
130 version into position. The <command>install</command> command
131 provided by <application>Coreutils</application> has already
132 implemented this and most packages use it to install binaries and
133 libraries. So you won't be troubled by this issue most of the time.
134 However, the install process of some packages (notably Mozilla JS
135 in BLFS) just overwrites the file if it exists and causes crash, so
136 it's safer to save your work and close unneeded running processes
137 before updating a package.</para>
138 </listitem>
139 </itemizedlist>
140
141 </sect2>
142
143 <sect2>
144 <title>Package Management Techniques</title>
145
146 <para>The following are some common package management techniques. Before
147 making a decision on a package manager, do some research on the various
148 techniques, particularly the drawbacks of the particular scheme.</para>
149
150 <sect3>
151 <title>It is All in My Head!</title>
152
153 <para>Yes, this is a package management technique. Some folks do not find
154 the need for a package manager because they know the packages intimately
155 and know what files are installed by each package. Some users also do not
156 need any package management because they plan on rebuilding the entire
157 system when a package is changed.</para>
158
159 </sect3>
160
161 <sect3>
162 <title>Install in Separate Directories</title>
163
164 <para>This is a simplistic package management that does not need any extra
165 package to manage the installations. Each package is installed in a
166 separate directory. For example, package foo-1.1 is installed in
167 <filename class='directory'>/usr/pkg/foo-1.1</filename>
168 and a symlink is made from <filename>/usr/pkg/foo</filename> to
169 <filename class='directory'>/usr/pkg/foo-1.1</filename>. When installing
170 a new version foo-1.2, it is installed in
171 <filename class='directory'>/usr/pkg/foo-1.2</filename> and the previous
172 symlink is replaced by a symlink to the new version.</para>
173
174 <para>Environment variables such as <envar>PATH</envar>,
175 <envar>LD_LIBRARY_PATH</envar>, <envar>MANPATH</envar>,
176 <envar>INFOPATH</envar> and <envar>CPPFLAGS</envar> need to be expanded to
177 include <filename>/usr/pkg/foo</filename>. For more than a few packages,
178 this scheme becomes unmanageable.</para>
179
180 </sect3>
181
182 <sect3>
183 <title>Symlink Style Package Management</title>
184
185 <para>This is a variation of the previous package management technique.
186 Each package is installed similar to the previous scheme. But instead of
187 making the symlink, each file is symlinked into the
188 <filename class='directory'>/usr</filename> hierarchy. This removes the
189 need to expand the environment variables. Though the symlinks can be
190 created by the user to automate the creation, many package managers have
191 been written using this approach. A few of the popular ones include Stow,
192 Epkg, Graft, and Depot.</para>
193
194 <para>The installation needs to be faked, so that the package thinks that
195 it is installed in <filename class="directory">/usr</filename> though in
196 reality it is installed in the
197 <filename class="directory">/usr/pkg</filename> hierarchy. Installing in
198 this manner is not usually a trivial task. For example, consider that you
199 are installing a package libfoo-1.1. The following instructions may
200 not install the package properly:</para>
201
202<screen role="nodump"><userinput>./configure --prefix=/usr/pkg/libfoo/1.1
203make
204make install</userinput></screen>
205
206 <para>The installation will work, but the dependent packages may not link
207 to libfoo as you would expect. If you compile a package that links against
208 libfoo, you may notice that it is linked to
209 <filename class='libraryfile'>/usr/pkg/libfoo/1.1/lib/libfoo.so.1</filename>
210 instead of <filename class='libraryfile'>/usr/lib/libfoo.so.1</filename>
211 as you would expect. The correct approach is to use the
212 <envar>DESTDIR</envar> strategy to fake installation of the package. This
213 approach works as follows:</para>
214
215<screen role="nodump"><userinput>./configure --prefix=/usr
216make
217make DESTDIR=/usr/pkg/libfoo/1.1 install</userinput></screen>
218
219 <para>Most packages support this approach, but there are some which do not.
220 For the non-compliant packages, you may either need to manually install the
221 package, or you may find that it is easier to install some problematic
222 packages into <filename class='directory'>/opt</filename>.</para>
223
224 </sect3>
225
226 <sect3>
227 <title>Timestamp Based</title>
228
229 <para>In this technique, a file is timestamped before the installation of
230 the package. After the installation, a simple use of the
231 <command>find</command> command with the appropriate options can generate
232 a log of all the files installed after the timestamp file was created. A
233 package manager written with this approach is install-log.</para>
234
235 <para>Though this scheme has the advantage of being simple, it has two
236 drawbacks. If, during installation, the files are installed with any
237 timestamp other than the current time, those files will not be tracked by
238 the package manager. Also, this scheme can only be used when one package
239 is installed at a time. The logs are not reliable if two packages are
240 being installed on two different consoles.</para>
241
242 </sect3>
243
244 <sect3>
245 <title>Tracing Installation Scripts</title>
246
247 <para>In this approach, the commands that the installation scripts perform
248 are recorded. There are two techniques that one can use:</para>
249
250 <para>The <envar>LD_PRELOAD</envar> environment variable can be set to
251 point to a library to be preloaded before installation. During
252 installation, this library tracks the packages that are being installed by
253 attaching itself to various executables such as <command>cp</command>,
254 <command>install</command>, <command>mv</command> and tracking the system
255 calls that modify the filesystem. For this approach to work, all the
256 executables need to be dynamically linked without the suid or sgid bit.
257 Preloading the library may cause some unwanted side-effects during
258 installation. Therefore, it is advised that one performs some tests to
259 ensure that the package manager does not break anything and logs all the
260 appropriate files.</para>
261
262 <para>The second technique is to use <command>strace</command>, which
263 logs all system calls made during the execution of the installation
264 scripts.</para>
265 </sect3>
266
267 <sect3>
268 <title>Creating Package Archives</title>
269
270 <para>In this scheme, the package installation is faked into a separate
271 tree as described in the Symlink style package management. After the
272 installation, a package archive is created using the installed files.
273 This archive is then used to install the package either on the local
274 machine or can even be used to install the package on other machines.</para>
275
276 <para>This approach is used by most of the package managers found in the
277 commercial distributions. Examples of package managers that follow this
278 approach are RPM (which, incidentally, is required by the <ulink
279 url="http://refspecs.linuxfoundation.org/lsb.shtml">Linux
280 Standard Base Specification</ulink>), pkg-utils, Debian's apt, and
281 Gentoo's Portage system. A hint describing how to adopt this style of
282 package management for LFS systems is located at <ulink
283 url="&hints-root;fakeroot.txt"/>.</para>
284
285 <para>Creation of package files that include dependency information is
286 complex and is beyond the scope of LFS.</para>
287
288 <para>Slackware uses a <command>tar</command> based system for package
289 archives. This system purposely does not handle package dependencies
290 as more complex package managers do. For details of Slackware package
291 management, see <ulink
292 url="http://www.slackbook.org/html/package-management.html"/>.</para>
293 </sect3>
294
295 <sect3>
296 <title>User Based Management</title>
297
298 <para>This scheme, unique to LFS, was devised by Matthias Benkmann, and is
299 available from the <ulink url="&hints-root;">Hints Project</ulink>. In
300 this scheme, each package is installed as a separate user into the
301 standard locations. Files belonging to a package are easily identified by
302 checking the user ID. The features and shortcomings of this approach are
303 too complex to describe in this section. For the details please see the
304 hint at <ulink url="&hints-root;more_control_and_pkg_man.txt"/>.</para>
305
306 </sect3>
307
308 </sect2>
309
310 <sect2>
311 <title>Deploying LFS on Multiple Systems</title>
312
313 <para>One of the advantages of an LFS system is that there are no files that
314 depend on the position of files on a disk system. Cloning an LFS build to
315 another computer with the same architecture as the base system is as
316 simple as using <command>tar</command> on the LFS partition that contains
317 the root directory (about 250MB uncompressed for a base LFS build), copying
318 that file via network transfer or CD-ROM to the new system and expanding
319 it. From that point, a few configuration files will have to be changed.
320 Configuration files that may need to be updated include:
321 <filename>/etc/hosts</filename>,
322 <filename>/etc/fstab</filename>,
323 <filename>/etc/passwd</filename>,
324 <filename>/etc/group</filename>,
325 <phrase revision="systemd">
326 <filename>/etc/shadow</filename>, and
327 <filename>/etc/ld.so.conf</filename>.
328 </phrase>
329 <phrase revision="sysv">
330 <filename>/etc/shadow</filename>,
331 <filename>/etc/ld.so.conf</filename>,
332 <filename>/etc/sysconfig/rc.site</filename>,
333 <filename>/etc/sysconfig/network</filename>, and
334 <filename>/etc/sysconfig/ifconfig.eth0</filename>.
335 </phrase>
336 </para>
337
338 <para>A custom kernel may need to be built for the new system depending on
339 differences in system hardware and the original kernel
340 configuration.</para>
341
342 <note><para>There have been some reports of issues when copying between
343 similar but not identical architectures. For instance, the instruction set
344 for an Intel system is not identical with an AMD processor and later
345 versions of some processors may have instructions that are unavailable in
346 earlier versions.</para></note>
347
348 <para>Finally the new system has to be made bootable via <xref
349 linkend="ch-bootable-grub"/>.</para>
350
351 </sect2>
352
353</sect1>
Note: See TracBrowser for help on using the repository browser.