1
0

pkgmgt.xml 13 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283
  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. <sect1 id="ch-system-pkgmgt">
  8. <?dbhtml filename="pkgmgt.html"?>
  9. <title>Package Management</title>
  10. <para>Package Management is an often requested addition to the LFS Book. A
  11. Package Manager allows tracking the installation of files making it easy to
  12. remove and upgrade packages. As well as the binary and library files, a
  13. package manager will handle the installation of configuration files. Before
  14. you begin to wonder, NO&mdash;this section will not talk about nor recommend
  15. any particular package manager. What it provides is a roundup of the more
  16. popular techniques and how they work. The perfect package manager for you may
  17. be among these techniques or may be a combination of two or more of these
  18. techniques. This section briefly mentions issues that may arise when upgrading
  19. packages.</para>
  20. <para>Some reasons why no package manager is mentioned in LFS or BLFS
  21. include:</para>
  22. <itemizedlist>
  23. <listitem>
  24. <para>Dealing with package management takes the focus away from the goals
  25. of these books&mdash;teaching how a Linux system is built.</para>
  26. </listitem>
  27. <listitem>
  28. <para>There are multiple solutions for package management, each having
  29. its strengths and drawbacks. Including one that satisfies all audiences
  30. is difficult.</para>
  31. </listitem>
  32. </itemizedlist>
  33. <para>There are some hints written on the topic of package management. Visit
  34. the <ulink url="&hints-index;">Hints Project</ulink> and see if one of them
  35. fits your need.</para>
  36. <sect2>
  37. <title>Upgrade Issues</title>
  38. <para>A Package Manager makes it easy to upgrade to newer versions when they
  39. are released. Generally the instructions in the LFS and BLFS Book can be
  40. used to upgrade to the newer versions. Here are some points that you should
  41. be aware of when upgrading packages, especially on a running system.</para>
  42. <itemizedlist>
  43. <listitem>
  44. <para>If one of the toolchain packages (Glibc, GCC or Binutils) needs
  45. to be upgraded to a newer minor version, it is safer to rebuild LFS.
  46. Though you <emphasis>may</emphasis> be able to get by rebuilding all
  47. the packages in their dependency order, we do not recommend it. For
  48. example, if glibc-2.2.x needs to be updated to glibc-2.3.x, it is safer
  49. to rebuild. For micro version updates, a simple reinstallation usually
  50. works, but is not guaranteed. For example, upgrading from glibc-2.3.4
  51. to glibc-2.3.5 will not usually cause any problems.</para>
  52. </listitem>
  53. <listitem>
  54. <para>If a package containing a shared library is updated, and if the
  55. name of the library changes, then all the packages dynamically linked
  56. to the library need to be recompiled to link against the newer library.
  57. (Note that there is no correlation between the package version and the
  58. name of the library.) For example, consider a package foo-1.2.3 that
  59. installs a shared library with name
  60. <filename class='libraryfile'>libfoo.so.1</filename>. Say you upgrade
  61. the package to a newer version foo-1.2.4 that installs a shared library
  62. with name <filename class='libraryfile'>libfoo.so.2</filename>. In this
  63. case, all packages that are dynamically linked to
  64. <filename class='libraryfile'>libfoo.so.1</filename> need to be
  65. recompiled to link against
  66. <filename class='libraryfile'>libfoo.so.2</filename>. Note that you
  67. should not remove the previous libraries until the dependent packages
  68. are recompiled.</para>
  69. </listitem>
  70. </itemizedlist>
  71. </sect2>
  72. <sect2>
  73. <title>Package Management Techniques</title>
  74. <para>The following are some common package management techniques. Before
  75. making a decision on a package manager, do some research on the various
  76. techniques, particularly the drawbacks of the particular scheme.</para>
  77. <sect3>
  78. <title>It is All in My Head!</title>
  79. <para>Yes, this is a package management technique. Some folks do not find
  80. the need for a package manager because they know the packages intimately
  81. and know what files are installed by each package. Some users also do not
  82. need any package management because they plan on rebuilding the entire
  83. system when a package is changed.</para>
  84. </sect3>
  85. <sect3>
  86. <title>Install in Separate Directories</title>
  87. <para>This is a simplistic package management that does not need any extra
  88. package to manage the installations. Each package is installed in a
  89. separate directory. For example, package foo-1.1 is installed in
  90. <filename class='directory'>/usr/pkg/foo-1.1</filename>
  91. and a symlink is made from <filename>/usr/pkg/foo</filename> to
  92. <filename class='directory'>/usr/pkg/foo-1.1</filename>. When installing
  93. a new version foo-1.2, it is installed in
  94. <filename class='directory'>/usr/pkg/foo-1.2</filename> and the previous
  95. symlink is replaced by a symlink to the new version.</para>
  96. <para>Environment variables such as <envar>PATH</envar>,
  97. <envar>LD_LIBRARY_PATH</envar>, <envar>MANPATH</envar>,
  98. <envar>INFOPATH</envar> and <envar>CPPFLAGS</envar> need to be expanded to
  99. include <filename>/usr/pkg/foo</filename>. For more than a few packages,
  100. this scheme becomes unmanageable.</para>
  101. </sect3>
  102. <sect3>
  103. <title>Symlink Style Package Management</title>
  104. <para>This is a variation of the previous package management technique.
  105. Each package is installed similar to the previous scheme. But instead of
  106. making the symlink, each file is symlinked into the
  107. <filename class='directory'>/usr</filename> hierarchy. This removes the
  108. need to expand the environment variables. Though the symlinks can be
  109. created by the user to automate the creation, many package managers have
  110. been written using this approach. A few of the popular ones include Stow,
  111. Epkg, Graft, and Depot.</para>
  112. <para>The installation needs to be faked, so that the package thinks that
  113. it is installed in <filename class="directory">/usr</filename> though in
  114. reality it is installed in the
  115. <filename class="directory">/usr/pkg</filename> hierarchy. Installing in
  116. this manner is not usually a trivial task. For example, consider that you
  117. are installing a package libfoo-1.1. The following instructions may
  118. not install the package properly:</para>
  119. <screen role="nodump"><userinput>./configure --prefix=/usr/pkg/libfoo/1.1
  120. make
  121. make install</userinput></screen>
  122. <para>The installation will work, but the dependent packages may not link
  123. to libfoo as you would expect. If you compile a package that links against
  124. libfoo, you may notice that it is linked to
  125. <filename class='libraryfile'>/usr/pkg/libfoo/1.1/lib/libfoo.so.1</filename>
  126. instead of <filename class='libraryfile'>/usr/lib/libfoo.so.1</filename>
  127. as you would expect. The correct approach is to use the
  128. <envar>DESTDIR</envar> strategy to fake installation of the package. This
  129. approach works as follows:</para>
  130. <screen role="nodump"><userinput>./configure --prefix=/usr
  131. make
  132. make DESTDIR=/usr/pkg/libfoo/1.1 install</userinput></screen>
  133. <para>Most packages support this approach, but there are some which do not.
  134. For the non-compliant packages, you may either need to manually install the
  135. package, or you may find that it is easier to install some problematic
  136. packages into <filename class='directory'>/opt</filename>.</para>
  137. </sect3>
  138. <sect3>
  139. <title>Timestamp Based</title>
  140. <para>In this technique, a file is timestamped before the installation of
  141. the package. After the installation, a simple use of the
  142. <command>find</command> command with the appropriate options can generate
  143. a log of all the files installed after the timestamp file was created. A
  144. package manager written with this approach is install-log.</para>
  145. <para>Though this scheme has the advantage of being simple, it has two
  146. drawbacks. If, during installation, the files are installed with any
  147. timestamp other than the current time, those files will not be tracked by
  148. the package manager. Also, this scheme can only be used when one package
  149. is installed at a time. The logs are not reliable if two packages are
  150. being installed on two different consoles.</para>
  151. </sect3>
  152. <sect3>
  153. <title>Tracing Installation Scripts</title>
  154. <para>In this approach, the commands that the installation scripts perform
  155. are recorded. There are two techniques that one can use:</para>
  156. <para>The <envar>LD_PRELOAD</envar> environment variable can be set to
  157. point to a library to be preloaded before installation. During
  158. installation, this library tracks the packages that are being installed by
  159. attaching itself to various executables such as <command>cp</command>,
  160. <command>install</command>, <command>mv</command> and tracking the system
  161. calls that modify the filesystem. For this approach to work, all the
  162. executables need to be dynamically linked without the suid or sgid bit.
  163. Preloading the library may cause some unwanted side-effects during
  164. installation. Therefore, it is advised that one performs some tests to
  165. ensure that the package manager does not break anything and logs all the
  166. appropriate files.</para>
  167. <para>The second technique is to use <command>strace</command>, which
  168. logs all system calls made during the execution of the installation
  169. scripts.</para>
  170. </sect3>
  171. <sect3>
  172. <title>Creating Package Archives</title>
  173. <para>In this scheme, the package installation is faked into a separate
  174. tree as described in the Symlink style package management. After the
  175. installation, a package archive is created using the installed files.
  176. This archive is then used to install the package either on the local
  177. machine or can even be used to install the package on other machines.</para>
  178. <para>This approach is used by most of the package managers found in the
  179. commercial distributions. Examples of package managers that follow this
  180. approach are RPM (which, incidentally, is required by the <ulink
  181. url="http://www.linux-foundation.org/en/Specifications">Linux
  182. Standard Base Specification</ulink>), pkg-utils, Debian's apt, and
  183. Gentoo's Portage system. A hint describing how to adopt this style of
  184. package management for LFS systems is located at <ulink
  185. url="&hints-root;fakeroot.txt"/>.</para>
  186. <para>Creation of package files that include dependency information is
  187. complex and is beyond the scope of LFS.</para>
  188. <para>Slackware uses a <command>tar</command> based system for package
  189. archives. This system purposely does not handle package dependencies
  190. as more complex package managers do. For details of Slackware package
  191. management, see <ulink
  192. url="http://www.slackbook.org/html/package-management.html"/>.</para>
  193. </sect3>
  194. <sect3>
  195. <title>User Based Management</title>
  196. <para>This scheme, unique to LFS, was devised by Matthias Benkmann, and is
  197. available from the <ulink url="&hints-index;">Hints Project</ulink>. In
  198. this scheme, each package is installed as a separate user into the
  199. standard locations. Files belonging to a package are easily identified by
  200. checking the user ID. The features and shortcomings of this approach are
  201. too complex to describe in this section. For the details please see the
  202. hint at <ulink url="&hints-root;more_control_and_pkg_man.txt"/>.</para>
  203. </sect3>
  204. </sect2>
  205. <sect2>
  206. <title>Deploying LFS on Multiple Systems</title>
  207. <para>One of the advantages of an LFS system is that there are no files that
  208. depend on the position of files on a disk system. Cloning an LFS build to
  209. another computer with an architecture similar to the base system is as
  210. simple as using <command>tar</command> on the LFS partition that contains
  211. the root directory (about 250MB uncompressed for a base LFS build), copying
  212. that file via network transfer or CD-ROM to the new system and expanding
  213. it. From that point, a few configuration files will have to be changed.
  214. Configuration files that may need to be updated include:
  215. <filename>/etc/hosts</filename>,
  216. <filename>/etc/fstab</filename>,
  217. <filename>/etc/passwd</filename>,
  218. <filename>/etc/group</filename>,
  219. <filename>/etc/shadow</filename>,
  220. <filename>/etc/ld.so.conf</filename>,
  221. <filename>/etc/scsi_id.config</filename>,
  222. <filename>/etc/sysconfig/network</filename> and
  223. <filename>/etc/sysconfig/network-devices/ifconfig.eth0/ipv4</filename>.
  224. </para>
  225. <para>A custom kernel may need to be built for the new system depending on
  226. differences in system hardware and the original kernel
  227. configuration.</para>
  228. <para>Finally the new system has to be made bootable via <xref
  229. linkend="ch-bootable-grub"/>.</para>
  230. </sect2>
  231. </sect1>