Changeset 1f24363


Ignore:
Timestamp:
05/07/2005 12:07:44 PM (17 years ago)
Author:
Manuel Canales Esparcia <manuel@…>
Branches:
10.0, 10.1, 11.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, xry111/git-date, xry111/git-date-for-trunk, xry111/git-date-test
Children:
d5f2a3f
Parents:
2957da9
Message:

Tagged pkgmgt.xml

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

File:
1 edited

Legend:

Unmodified
Added
Removed
  • introduction/important/pkgmgt.xml

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