source: final-system/common/pkgmgt.xml@ ee3f926

Last change on this file since ee3f926 was 1d74ae6, checked in by Chris Staub <chris@…>, 18 years ago

Updated date

  • Property mode set to 100644
File size: 10.6 KB
RevLine 
[c048db9]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
[1e59f09]13 <para>Package Management is an often-requested addition to the CLFS Book. A
[c048db9]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
[1e59f09]22 <para>Some reasons why no specific package manager is recommended in
23 CLFS or BLFS include:</para>
[c048db9]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
[8c50f0e]33 its strengths and drawbacks. Including one that satisfies all audiences
[c048db9]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
[1e59f09]46 are released. Generally the instructions in the CLFS and BLFS Book can be
[c048db9]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
[1e59f09]53 to be upgraded to a newer minor version, it is safer to
54 rebuild CLFS. Though you <emphasis>may</emphasis> be able to get by
55 rebuilding all the packages in their dependency order, we do not
56 recommend it. For example, if glibc-2.2.x needs to be updated to
57 glibc-2.3.x, it is safer to rebuild. For micro version updates, a
58 simple reinstallation usually works, but is not guaranteed. For
59 example, upgrading from glibc-2.3.4 to glibc-2.3.5 will not
60 usually cause any problems.</para>
[c048db9]61 </listitem>
62
63 <listitem>
64 <para>If a package containing a shared library is updated, and if the
65 name of the library changes, then all the packages dynamically linked
66 to the library need to be recompiled to link against the newer library.
67 (Note that there is no correlation between the package version and the
68 name of the library.) For example, consider a package foo-1.2.3 that
69 installs a shared library with name
70 <filename class='libraryfile'>libfoo.so.1</filename>. Say you upgrade
71 the package to a newer version foo-1.2.4 that installs a shared library
72 with name <filename class='libraryfile'>libfoo.so.2</filename>. In this
73 case, all packages that are dynamically linked to
74 <filename class='libraryfile'>libfoo.so.1</filename> need to be
75 recompiled to link against
76 <filename class='libraryfile'>libfoo.so.2</filename>. Note that you
77 should not remove the previous libraries until the dependent packages
78 are recompiled.</para>
79 </listitem>
80
81 <listitem>
82 <para>If you are upgrading a running system, be on the lookout for
83 packages that use <command>cp</command> instead of
84 <command>install</command> to install files. The latter command is
85 usually safer if the executable or library is already loaded in memory.
86 </para>
87 </listitem>
88 </itemizedlist>
89
90 </sect2>
91
92 <sect2>
93 <title>Package Management Techniques</title>
94
95 <para>The following are some common package management techniques. Before
96 making a decision on a package manager, do some research on the various
97 techniques, particularly the drawbacks of the particular scheme.</para>
98
99 <sect3>
100 <title>It is All in My Head!</title>
101
102 <para>Yes, this is a package management technique. Some folks do not find
103 the need for a package manager because they know the packages intimately
104 and know what files are installed by each package. Some users also do not
105 need any package management because they plan on rebuilding the entire
106 system when a package is changed.</para>
107
108 </sect3>
109
110 <sect3>
111 <title>Install in Separate Directories</title>
112
113 <para>This is a simplistic package management that does not need any extra
114 package to manage the installations. Each package is installed in a
115 separate directory. For example, package foo-1.1 is installed in
116 <filename class='directory'>/usr/pkg/foo-1.1</filename>
117 and a symlink is made from <filename>/usr/pkg/foo</filename> to
118 <filename class='directory'>/usr/pkg/foo-1.1</filename>. When installing
119 a new version foo-1.2, it is installed in
120 <filename class='directory'>/usr/pkg/foo-1.2</filename> and the previous
121 symlink is replaced by a symlink to the new version.</para>
122
123 <para>Environment variables such as <envar>PATH</envar>,
124 <envar>LD_LIBRARY_PATH</envar>, <envar>MANPATH</envar>,
125 <envar>INFOPATH</envar> and <envar>CPPFLAGS</envar> need to be expanded to
126 include <filename>/usr/pkg/foo</filename>. For more than a few packages,
127 this scheme becomes unmanageable.</para>
128
129 </sect3>
130
131 <sect3>
132 <title>Symlink Style Package Management</title>
133
134 <para>This is a variation of the previous package management technique.
135 Each package is installed similar to the previous scheme. But instead of
136 making the symlink, each file is symlinked into the
137 <filename class='directory'>/usr</filename> hierarchy. This removes the
138 need to expand the environment variables. Though the symlinks can be
139 created by the user to automate the creation, many package managers have
140 been written using this approach. A few of the popular ones include Stow,
141 Epkg, Graft, and Depot.</para>
142
143 <para>The installation needs to be faked, so that the package thinks that
144 it is installed in <filename class="directory">/usr</filename> though in
145 reality it is installed in the
146 <filename class="directory">/usr/pkg</filename> hierarchy. Installing in
147 this manner is not usually a trivial task. For example, consider that you
148 are installing a package libfoo-1.1. The following instructions may
149 not install the package properly:</para>
150
151<screen role="nodump"><userinput>./configure --prefix=/usr/pkg/libfoo/1.1
152make
153make install</userinput></screen>
154
155 <para>The installation will work, but the dependent packages may not link
156 to libfoo as you would expect. If you compile a package that links against
157 libfoo, you may notice that it is linked to
158 <filename class='libraryfile'>/usr/pkg/libfoo/1.1/lib/libfoo.so.1</filename>
159 instead of <filename class='libraryfile'>/usr/lib/libfoo.so.1</filename>
160 as you would expect. The correct approach is to use the
161 <envar>DESTDIR</envar> strategy to fake installation of the package. This
162 approach works as follows:</para>
163
164<screen role="nodump"><userinput>./configure --prefix=/usr
165make
166make DESTDIR=/usr/pkg/libfoo/1.1 install</userinput></screen>
167
168 <para>Most packages support this approach, but there are some which do not.
169 For the non-compliant packages, you may either need to manually install the
170 package, or you may find that it is easier to install some problematic
171 packages into <filename class='directory'>/opt</filename>.</para>
172
173 </sect3>
174
175 <sect3>
176 <title>Timestamp Based</title>
177
178 <para>In this technique, a file is timestamped before the installation of
179 the package. After the installation, a simple use of the
180 <command>find</command> command with the appropriate options can generate
181 a log of all the files installed after the timestamp file was created. A
182 package manager written with this approach is install-log.</para>
183
184 <para>Though this scheme has the advantage of being simple, it has two
185 drawbacks. If, during installation, the files are installed with any
186 timestamp other than the current time, those files will not be tracked by
187 the package manager. Also, this scheme can only be used when one package
188 is installed at a time. The logs are not reliable if two packages are
189 being installed on two different consoles.</para>
190
191 </sect3>
192
193 <sect3>
194 <title>LD_PRELOAD Based</title>
195
196 <para>In this approach, a library is preloaded before installation. During
197 installation, this library tracks the packages that are being installed by
198 attaching itself to various executables such as <command>cp</command>,
199 <command>install</command>, <command>mv</command> and tracking the system
200 calls that modify the filesystem. For this approach to work, all the
201 executables need to be dynamically linked without the suid or sgid bit.
202 Preloading the library may cause some unwanted side-effects during
203 installation. Therefore, it is advised that one performs some tests to
204 ensure that the package manager does not break anything and logs all the
205 appropriate files.</para>
206
207 </sect3>
208
209 <sect3>
210 <title>Creating Package Archives</title>
211
212 <para>In this scheme, the package installation is faked into a separate
213 tree as described in the Symlink style package management. After the
214 installation, a package archive is created using the installed files.
215 This archive is then used to install the package either on the local
216 machine or can even be used to install the package on other machines.</para>
217
218 <para>This approach is used by most of the package managers found in the
219 commercial distributions. Examples of package managers that follow this
220 approach are RPM (which, incidentally, is required by the <ulink
221 url="http://lsbbook.gforge.freestandards.org/package.html#RPM">Linux
222 Standard Base Specification</ulink>), pkg-utils, Debian's apt, and
223 Gentoo's Portage system. A hint describing how to adopt this style of
[2877cb4]224 package management for CLFS systems is located at <ulink
[c048db9]225 url="&hints-root;/fakeroot.txt"/>.</para>
226
227 </sect3>
228
229 </sect2>
230
231</sect1>
Note: See TracBrowser for help on using the repository browser.