Changeset 1f24363 for introduction/important/pkgmgt.xml
- Timestamp:
- 05/07/2005 12:07:44 PM (19 years ago)
- Branches:
- 10.0, 10.1, 11.0, 11.1, 11.2, 11.3, 12.0, 12.1, 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, kea, ken/TL2024, ken/inkscape-core-mods, ken/tuningfonts, krejzi/svn, lazarus, lxqt, nosym, perl-modules, plabs/newcss, plabs/python-mods, python3.11, qt5new, rahul/power-profiles-daemon, renodr/vulkan-addition, systemd-11177, systemd-13485, trunk, upgradedb, xry111/intltool, xry111/llvm18, xry111/soup3, xry111/test-20220226, xry111/xf86-video-removal
- Children:
- d5f2a3f
- Parents:
- 2957da9
- File:
-
- 1 edited
-
introduction/important/pkgmgt.xml (modified) (1 diff)
Legend:
- Unmodified
- Added
- Removed
-
introduction/important/pkgmgt.xml
r2957da9 r1f24363 7 7 8 8 <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—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—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—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—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 133 143 make 134 make install</ command></userinput></screen>135 136 <para>The installation will work, but the dependent packages may not link to137 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 correct140 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=/usr144 make 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 144 154 make 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 155 make 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> 217 224 218 225 </sect1>
Note:
See TracChangeset
for help on using the changeset viewer.
