source: BOOK/final-system/common/pkgmgt.xml@ 3114d90

clfs-1.2 clfs-2.1 clfs-3.0.0-systemd clfs-3.0.0-sysvinit systemd sysvinit
Last change on this file since 3114d90 was 1322a63, checked in by Jim Gifford <clfs@…>, 19 years ago

r1169@server (orig r1167): chris | 2006-02-11 19:55:38 -0800
Various text updates

  • Property mode set to 100644
File size: 11.2 KB
Line 
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&mdash;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
22 <para>Some reasons why no specific package manager is recommended in LFS or
23 BLFS include:</para>
24
25 <itemizedlist>
26 <listitem>
27 <para>Dealing with package management takes the focus away from the goals
28 of these books&mdash;teaching how a Linux system is built.</para>
29 </listitem>
30
31 <listitem>
32 <para>There are multiple solutions for package management, each having
33 its strengths and drawbacks. Including one that satisfies all audiences
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.
54 Though, you <emphasis>may</emphasis> be able to get by rebuilding all
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
151make
152make 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
164make
165make 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>
Note: See TracBrowser for help on using the repository browser.