source: chapter08/pkgmgt.xml@ 59fef4c

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 xry111/tester-nohack
Last change on this file since 59fef4c was 59fef4c, checked in by Xi Ruoyao <xry111@…>, 15 months ago

generalize ken's note for shared library update, ...

and move it into package management section

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