source: introduction/important/pkgmgt.xml@ aa15d3e

10.0 10.1 11.0 6.0 6.1 6.2 6.2.0 6.2.0-rc1 6.2.0-rc2 6.3 6.3-rc1 6.3-rc2 6.3-rc3 7.10 7.4 7.5 7.6 7.6-blfs 7.6-systemd 7.7 7.8 7.9 8.0 8.1 8.2 8.3 8.4 9.0 9.1 basic bdubbs/svn elogind gnome kde5-13430 kde5-14269 kde5-14686 ken/refactor-virt krejzi/svn lazarus nosym perl-modules qt5new systemd-11177 systemd-13485 trunk v5_1 xry111/git-date xry111/git-date-for-trunk xry111/git-date-test
Last change on this file since aa15d3e was aa15d3e, checked in by Igor Živković <igor@…>, 17 years ago

applied Randy's grammar and spelling fixes

git-svn-id: svn://svn.linuxfromscratch.org/BLFS/trunk/BOOK@2232 af4574ff-66df-0310-9fd7-8a98e5e911e0

  • Property mode set to 100644
File size: 9.7 KB
Line 
1<sect1 id="intro-important-pkgmgt">
2<?dbhtml filename="pkgmgt.html"?>
3<title>Package Management</title>
4
5<para>Package Management is an often requested addition
6to the <acronym>LFS</acronym> Book. A Package Manager allows tracking
7the installation of files making it easy to remove and upgrade packages.
8And before you begin to wonder, NO - this section does not talk about any
9particular package manager, nor does it recommend one. What it provides is
10a roundup of the more popular techniques and how they work. The perfect
11package manager for you may be among these techniques or may be a combination
12of two or more of these techniques. This section briefly mentions
13issues that may arise when upgrading packages.</para>
14
15<para>Some reasons why no package manager is mentioned in <acronym>LFS</acronym>
16or <acronym>BLFS</acronym>:</para>
17
18<itemizedlist>
19<listitem><para>Dealing with package management takes the focus away from
20the goals of these books - Teaching how a Linux System is built.</para></listitem>
21<listitem><para>There are multiple solutions for package management, each having
22its strengths and drawbacks. Including one that satifies all audiences is
23difficult.</para></listitem>
24</itemizedlist>
25
26<para>There are some hints written on the topic of package management. Visit
27the <ulink url="http://www.linuxfromscratch.org/hints/">Hints subproject</ulink>
28to find if one of them fits your need.</para>
29
30
31<sect2>
32<title>Upgrade Issues</title>
33
34<para>A Package Manager makes it easy to upgrade to newer versions as and when they
35are released. Generally the instructions in the <acronym>LFS</acronym> and
36<acronym>BLFS</acronym> Book can be used to upgrade to the newer versions.
37Following are some points that you should be aware of when upgrading
38packages, especially on a running system.</para>
39
40<itemizedlist>
41<listitem><para>It is recommended that if one of the toolchain package (glibc, gcc,
42binutils) needs to be upgraded to a newer minor vesion, it is safer to rebuild
43<acronym>LFS</acronym>. Though you <emphasis>may</emphasis> be able to get by
44rebuilding all the packages in their dependency order. We do not recommend the
45latter. For example, if glibc-2.2.x needs to be updated to glibc-2.3.x, it is safer
46to rebuild. For micro version updates, a simple reinstallation usually works, but
47is not guaranteed. For example, upgrading from glibc-2.3.1 to glibc-2.3.2 will not
48usually cause any problems.</para></listitem>
49<listitem><para>If a package containing a shared library is updated, and if the
50soname of the library changes, then all the packages dynamically linked to the
51library need to be recompiled to link against the newer library. (Note that there
52is no corelation between the package version and the soname of the library.) For
53example, consider a package foo-1.2.3 that installs a shared library with soname
54<filename>libfoo.so.1</filename>. Say you upgrade the package to a newer version
55foo-1.2.4 that installs a shared library with soname <filename>libfoo.so.2</filename>.
56In this case, all packages that are dynamically linked to <filename>libfoo.so.1</filename>
57need to be recompiled to link against <filename>libfoo.so.2</filename>. Note that
58you should not remove the previous libraries till the dependent packages are
59recompiled.</para></listitem>
60<listitem><para>If you are upgrading a running system, be on the lookout for
61packages that use <command>cp</command> instead of <command>install</command> to
62install files. The latter command is usually safer if the executable or library
63is already loaded in memory.</para></listitem>
64</itemizedlist>
65
66</sect2>
67
68
69<sect2>
70<title>Package Management Techniques</title>
71
72<para>The following are some common package management techniques. Before
73making a decision on a package manager, do a research on the various
74techniques, particularly the drawbacks of the particular scheme.</para>
75
76<sect3>
77<title>It is all in my head!</title>
78
79<para>Yes, this is a package management technique. Some folks do not find the
80need for a package manager because they know the packages intimately and know
81what files are installed by each package. Some users also do not need any
82package management because they plan on rebuilding the entire <acronym>LFS</acronym>
83when a package is changed.</para>
84
85</sect3>
86
87<sect3>
88<title>Install in separate directories</title>
89
90<para>This is a simplistic package management that does not need any extra package
91to manage the installations. Each package is installed in a separate directory.
92For example, package foo-1.1 is installed in <filename>/usr/pkg/foo-1.1</filename>
93and a symlink is made from <filename>/usr/pkg/foo</filename> to
94<filename>/usr/pkg/foo-1.1</filename>. When installing a new version foo-1.2,
95it is installed in <filename>/usr/pkg/foo-1.2</filename> and the previous
96symlink is replaced by a symlink to the new vesion.</para>
97
98<para>The environment variables such as those
99mentioned in <xref linkend="intro-important-beyond"/> need to be expanded to
100include <filename>/usr/pkg/foo</filename>. For more than a few packages,
101this scheme becomes unmanageable.</para>
102
103</sect3>
104
105<sect3>
106<title>Symlink style package management</title>
107
108<para>This is a variation of the previous package management technique. Each package
109is installed similar to the previous scheme. But instead of making the symlink,
110each file is symlinked into <filename>/usr</filename> hierarchy. This removes the need
111to expand the environment variables. Though the symlinks can be created by the user,
112to automate the creation, many package managers have been written on this approach.
113A few of the popular ones are Stow, Epkg, Graft, and Depot.</para>
114
115<para>The installation needs to be faked, so that the package thinks that it is
116installed in <filename class="directory">/usr</filename> though in reality it is installed in
117<filename class="directory">/usr/pkg</filename> hierarchy. Installing in this manner is not usually a trivial
118task. For example, consider that you are installing a package libfoo-1.1. The following
119instructions may not install the package properly:</para>
120
121<screen><userinput><command>./configure --prefix=/usr/pkg/libfoo/1.1 &amp;&amp;
122make &amp;&amp;
123make install</command></userinput></screen>
124
125<para>The installation will work, but the dependent packages may not link to
126libfoo as you would expect. If you compile a package that links against libfoo,
127you may notice that it is linked to <filename>/usr/pkg/libfoo/1.1/lib/libfoo.so.1</filename>
128instead of <filename>/usr/lib/libfoo.so.1</filename> as you would expect. The correct
129approach is to use <envar>DESTDIR</envar> strategy to fake installation of the package.
130This approach works as follows:</para>
131
132<screen><userinput><command>./configure --prefix=/usr &amp;&amp;
133make &amp;&amp;
134make DESTDIR=/usr/pkg/libfoo/1.1 install</command></userinput></screen>
135
136<para>Most of the packages do support this approach, but there are some which do not.
137For the non-compliant packages, you may either need to manually install the package,
138or you may find that it is easier to install some problematic packages into
139<filename>/opt</filename>.</para>
140
141</sect3>
142
143<sect3>
144<title>Timestamp based</title>
145
146<para>In this technique, a file is timestamped before the installation of the package.
147After the installation, a simple use of the <command>find</command> command with the
148appropriate options can generate a log of all the files installed after the timestamp
149file was created. A package manager written with this approach is install-log.</para>
150
151<para>Though this scheme has the advantage of being simple, it has two drawbacks.
152If during installation, the files are installed with any timestamp other than the
153current time, those files will not be tracked by the package manager. Also, this
154scheme can only be used when one package is installed at a time. The logs are not
155reliable if two packages are being installed on two different consoles.</para>
156
157</sect3>
158
159<sect3>
160<title>LD_PRELOAD based</title>
161
162<para>In this approach, a library is preloaded before installation. During
163installation, this library tracks the packages that are being installed by
164attaching itself to various executables such as <command>cp</command>,
165<command>install</command>, <command>mv</command> and tracking the system
166calls that modify the filesystem. For this approach to work, all the executables
167need to be dymanically linked without the suid or sgid bit. Preloading the
168library may cause some unwanted side-effects during installation; hence
169do perform some tests to ensure that the package manager does not break
170anything and logs all the appropriate files.</para>
171
172</sect3>
173
174<sect3>
175<title>Creating Package Archives</title>
176
177<para>In this scheme, the package installation is faked into a separate
178tree as described in the Symlink style package management. After the
179installation, a package archive is created using the installed files.
180This archive is then used to install the package either on the local
181machine or can even be used to install the package on other machines.</para>
182
183<para>This approach is used by most of the package managers found in the
184commercial distributions. Examples of package Managers that follow this
185approach are RPM, pkg-utils, Debian's apt, Gentoo's Portage system.</para>
186
187</sect3>
188
189<sect3>
190<title>User Based Management</title>
191
192<para>This scheme, that is unique to <acronym>LFS</acronym>, was
193devised by Matthias Benkmann, and is available from the <ulink
194url="http://www.linuxfromscratch.org/hints/">Hints Project</ulink>.
195In this scheme, each package is installed as a separate user into
196the standard locations. Files belonging to a package are easily
197identified by checking the user id. The features and shortcomings
198of this approach are too complex to describe in this section. For
199the details please see the hint at <ulink
200url="http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt"/>.</para>
201
202</sect3>
203
204</sect2>
205
206
207</sect1>
Note: See TracBrowser for help on using the repository browser.