source: introduction/important/pkgmgt.xml@ eede1a3

11.0 ken/refactor-virt lazarus qt5new trunk upgradedb
Last change on this file since eede1a3 was 45ab6c7, checked in by Xi Ruoyao <xry111@…>, 9 months ago

more SVN prop clean up

Remove "$LastChanged$" everywhere, and also some unused $Date$

  • Property mode set to 100644
File size: 10.9 KB
1<?xml version="1.0" encoding="ISO-8859-1"?>
2<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
3 "" [
4 <!ENTITY % general-entities SYSTEM "../../general.ent">
5 %general-entities;
8<sect1 id="pkgmgt">
9 <?dbhtml filename="pkgmgt.html"?>
11 <sect1info>
12 <date>$Date$</date>
13 </sect1info>
15 <title>Package Management</title>
17 <para>Package Management is an often requested addition
18 to the LFS Book. A Package Manager allows tracking
19 the installation of files making it easy to remove and upgrade packages.
20 And before you begin to wonder, NO&mdash;this section does not talk about any
21 particular package manager, nor does it recommend one. What it provides is
22 a roundup of the more popular techniques and how they work. The perfect
23 package manager for you may be among these techniques or may be a combination
24 of two or more of these techniques. This section briefly mentions
25 issues that may arise when upgrading packages.</para>
27 <para>Some reasons why no package manager is mentioned in LFS
28 or BLFS:</para>
30 <itemizedlist>
31 <listitem>
32 <para>Dealing with package management takes the focus away from
33 the goals of these books&mdash;teaching how a Linux system is built.</para>
34 </listitem>
35 <listitem>
36 <para>There are multiple solutions for package management, each having
37 its strengths and drawbacks. Including one that satisfies all audiences is
38 difficult.</para>
39 </listitem>
40 </itemizedlist>
42 <para>There are some hints written on the topic of package management. Visit
43 the <ulink url="&hints-root;">Hints subproject</ulink>
44 and see if one of them fits your need.</para>
46 <sect2>
47 <title>Upgrade Issues</title>
49 <para>A Package Manager makes it easy to upgrade to newer versions when
50 they are released. Generally the instructions in the LFS and BLFS Book can be
51 used to upgrade to the newer versions. Here are some points that you should
52 be aware of when upgrading packages, especially on a running system.</para>
54 <itemizedlist>
55 <listitem>
56 <para>If one of the toolchain packages
57 (<application>Glibc</application>, <application>GCC</application> or
58 <application>Binutils</application>) needs to be upgraded to a newer
59 minor version, it is safer to rebuild LFS. Though you
60 <emphasis>may</emphasis> be able to get by rebuilding all the packages
61 in their dependency order, we do not recommend it. For example, if
62 glibc-2.2.x needs to be updated to glibc-2.3.x, it is safer to rebuild.
63 For micro version updates, a simple reinstallation usually works, but
64 is not guaranteed. For example, upgrading from glibc-2.3.4 to
65 glibc-2.3.5 will not usually cause any problems.</para>
66 </listitem>
67 <listitem>
68 <para>If a package containing a shared library is updated, and if the
69 name of the library changes, then all the packages dynamically linked
70 to the library need to be recompiled to link against the newer library.
71 (Note that there is no correlation between the package version and the
72 name of the library.) For example, consider a package foo-1.2.3 that
73 installs a shared library with name
74 <filename class='libraryfile'></filename>. Say you upgrade
75 the package to a newer version foo-1.2.4 that installs a shared library
76 with name <filename class='libraryfile'></filename>. In this
77 case, all packages that are dynamically linked to
78 <filename class='libraryfile'></filename> need to be
79 recompiled to link against
80 <filename class='libraryfile'></filename>. Note that you
81 should not remove the previous libraries until the dependent packages
82 are recompiled.</para>
83 </listitem>
84 <listitem>
85 <para>If you are upgrading a running system, be on the lookout for packages
86 that use <command>cp</command> instead of <command>install</command>
87 to install files. The latter command is usually safer if the executable
88 or library is already loaded in memory.</para>
89 </listitem>
90 </itemizedlist>
92 </sect2>
94 <sect2>
95 <title>Package Management Techniques</title>
97 <para>The following are some common package management techniques. Before
98 making a decision on a package manager, do some research on the various
99 techniques, particularly the drawbacks of the particular scheme.</para>
101 <sect3>
102 <title>It is All in My Head!</title>
104 <para>Yes, this is a package management technique. Some folks do not find the
105 need for a package manager because they know the packages intimately and know
106 what files are installed by each package. Some users also do not need any
107 package management because they plan on rebuilding the entire system
108 when a package is changed.</para>
110 </sect3>
112 <sect3>
113 <title>Install in Separate Directories</title>
115 <para>This is a simplistic package management that does not need any
116 extra package to manage the installations. Each package is installed in a
117 separate directory. For example, package foo-1.1 is installed in
118 <filename class='directory'>/usr/pkg/foo-1.1</filename>
119 and a symlink is made from <filename>/usr/pkg/foo</filename> to
120 <filename class='directory'>/usr/pkg/foo-1.1</filename>. When installing
121 a new version foo-1.2, it is installed in
122 <filename class='directory'>/usr/pkg/foo-1.2</filename> and the previous
123 symlink is replaced by a symlink to the new version.</para>
125 <para>The environment variables such as those mentioned in
126 <quote><xref linkend="beyond"/></quote> need to be expanded to
127 include <filename>/usr/pkg/foo</filename>. For more than a few packages,
128 this scheme becomes unmanageable.</para>
130 </sect3>
132 <sect3>
133 <title>Symlink Style Package Management</title>
135 <para>This is a variation of the previous package management technique.
136 Each package is installed similar to the previous scheme. But instead of
137 making the symlink, each file is symlinked into the
138 <filename class='directory'>/usr</filename> hierarchy. This removes the
139 need to expand the environment variables. Though the symlinks can be
140 created by the user to automate the creation, many package managers have
141 been written using this approach. A few of the popular ones are Stow,
142 Epkg, Graft, and Depot.</para>
144 <para>The installation needs to be faked, so that the package thinks that it is
145 installed in <filename class="directory">/usr</filename> though in reality it is
146 installed in the <filename class="directory">/usr/pkg</filename> hierarchy.
147 Installing in this manner is not usually a trivial task. For example, consider
148 that you are installing a package libfoo-1.1. The following instructions may
149 not install the package properly:</para>
151<screen><userinput>./configure --prefix=/usr/pkg/libfoo/1.1
153make install</userinput></screen>
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/</filename>
159 instead of <filename class='libraryfile'>/usr/lib/</filename>
160 as you would expect. The correct approach is to use <envar>DESTDIR</envar>
161 strategy to fake installation of the package. This approach works as
162 follows:</para>
164<screen><userinput>./configure --prefix=/usr
166make DESTDIR=/usr/pkg/libfoo/1.1 install</userinput></screen>
168 <para>Most of the packages do support this approach, but there are some
169 which do not. For the non-compliant packages, you may either need to
170 manually install the package, or you may find that it is easier to install
171 some problematic packages into
172 <filename class='directory'>/opt</filename>.</para>
174 </sect3>
176 <sect3>
177 <title>Timestamp Based</title>
179 <para>In this technique, a file is timestamped before the installation of
180 the package. After the installation, a simple use of the
181 <command>find</command> command with the appropriate options can generate
182 a log of all the files installed after the timestamp file was created. A
183 package manager written with this approach is install-log.</para>
185 <para>Though this scheme has the advantage of being simple, it has two drawbacks.
186 If during installation, the files are installed with any timestamp other than the
187 current time, those files will not be tracked by the package manager. Also, this
188 scheme can only be used when one package is installed at a time. The logs are not
189 reliable if two packages are being installed on two different consoles.</para>
191 </sect3>
193 <sect3>
194 <title>LD_PRELOAD Based</title>
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 executables
201 need to be dynamically linked without the suid or sgid bit. Preloading the
202 library may cause some unwanted side-effects during installation. Therefore,
203 do perform some tests to ensure that the package manager does not break
204 anything and logs all the appropriate files.</para>
206 </sect3>
208 <sect3>
209 <title>Creating Package Archives</title>
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>
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, pkg-utils, Debian's apt, and Gentoo's Portage system.</para>
221 </sect3>
223 <sect3>
224 <title>User Based Management</title>
226 <para>This scheme, unique to LFS, was devised by Matthias Benkmann,
227 and is available from the <ulink url="&hints-root;">Hints
228 Project</ulink>. In this scheme, each package is installed as a separate user
229 into the standard locations. Files belonging to a package are easily identified
230 by checking the user ID. The features and shortcomings of this approach are
231 too complex to describe in this section. For the details please see the hint at <ulink
232 url="&hints-root;/downloads/files/more_control_and_pkg_man.txt"/>.</para>
234 </sect3>
236 </sect2>
Note: See TracBrowser for help on using the repository browser.