Author: manuel Date: 2005-05-07 06:07:44 -0600 (Sat, 07 May 2005) New Revision: 4014
Modified: trunk/BOOK/introduction/important/pkgmgt.xml Log: Tagged pkgmgt.xml Modified: trunk/BOOK/introduction/important/pkgmgt.xml =================================================================== --- trunk/BOOK/introduction/important/pkgmgt.xml 2005-05-07 11:50:08 UTC (rev 4013) +++ trunk/BOOK/introduction/important/pkgmgt.xml 2005-05-07 12:07:44 UTC (rev 4014) @@ -6,213 +6,220 @@ ]> <sect1 id="intro-important-pkgmgt"> -<sect1info> -<othername>$LastChangedBy$</othername> -<date>$Date$</date> -</sect1info> -<?dbhtml filename="pkgmgt.html"?> -<title>Package Management</title> + <?dbhtml filename="pkgmgt.html"?> -<para>Package Management is an often requested addition -to the <acronym>LFS</acronym> Book. A Package Manager allows tracking -the installation of files making it easy to remove and upgrade packages. -And before you begin to wonder, NO—this section does not talk about any -particular package manager, nor does it recommend one. What it provides is -a roundup of the more popular techniques and how they work. The perfect -package manager for you may be among these techniques or may be a combination -of two or more of these techniques. This section briefly mentions -issues that may arise when upgrading packages.</para> + <sect1info> + <othername>$LastChangedBy$</othername> + <date>$Date$</date> + </sect1info> -<para>Some reasons why no package manager is mentioned in <acronym>LFS</acronym> -or <acronym>BLFS</acronym>:</para> + <title>Package Management</title> -<itemizedlist> -<listitem><para>Dealing with package management takes the focus away from -the goals of these books—teaching how a Linux system is built.</para></listitem> -<listitem><para>There are multiple solutions for package management, each having -its strengths and drawbacks. Including one that satifies all audiences is -difficult.</para></listitem> -</itemizedlist> + <para>Package Management is an often requested addition + to the LFS Book. A Package Manager allows tracking + the installation of files making it easy to remove and upgrade packages. + And before you begin to wonder, NO—this section does not talk about any + particular package manager, nor does it recommend one. What it provides is + a roundup of the more popular techniques and how they work. The perfect + package manager for you may be among these techniques or may be a combination + of two or more of these techniques. This section briefly mentions + issues that may arise when upgrading packages.</para> -<para>There are some hints written on the topic of package management. Visit -the <ulink url="http://www.linuxfromscratch.org/hints/";>Hints subproject</ulink> -to find if one of them fits your need.</para> + <para>Some reasons why no package manager is mentioned in LFS + or BLFS:</para> + <itemizedlist> + <listitem> + <para>Dealing with package management takes the focus away from + the goals of these books—teaching how a Linux system is built.</para> + </listitem> + <listitem> + <para>There are multiple solutions for package management, each having + its strengths and drawbacks. Including one that satifies all audiences is + difficult.</para> + </listitem> + </itemizedlist> -<sect2> -<title>Upgrade Issues</title> + <para>There are some hints written on the topic of package management. Visit + the <ulink url="http://www.linuxfromscratch.org/hints/";>Hints subproject</ulink> + to find if one of them fits your need.</para> -<para>A Package Manager makes it easy to upgrade to newer versions when they -are released. Generally the instructions in the <acronym>LFS</acronym> and -<acronym>BLFS</acronym> Book can be used to upgrade to the newer versions. -Here are some points that you should be aware of when upgrading -packages, especially on a running system.</para> + <sect2> + <title>Upgrade Issues</title> -<itemizedlist> -<listitem><para>If one of the toolchain package (glibc, gcc, -binutils) needs to be upgraded to a newer minor vesion, it is safer to rebuild -<acronym>LFS</acronym>. Though you <emphasis>may</emphasis> be able to get by -rebuilding all the packages in their dependency order. We do not recommend it. -For example, if glibc-2.2.x needs to be updated to glibc-2.3.x, it is safer -to rebuild. For micro version updates, a simple reinstallation usually works, but -is not guaranteed. For example, upgrading from glibc-2.3.1 to glibc-2.3.2 will not -usually cause any problems.</para></listitem> -<listitem><para>If a package containing a shared library is updated, and if the -name of the library changes, then all the packages dynamically linked to the -library need to be recompiled to link against the newer library. (Note that there -is no corelation between the package version and the name of the library.) For -example, consider a package foo-1.2.3 that installs a shared library with name -<filename>libfoo.so.1</filename>. Say you upgrade the package to a newer version -foo-1.2.4 that installs a shared library with name <filename>libfoo.so.2</filename>. -In this case, all packages that are dynamically linked to <filename>libfoo.so.1</filename> -need to be recompiled to link against <filename>libfoo.so.2</filename>. Note that -you should not remove the previous libraries till the dependent packages are -recompiled.</para></listitem> -<listitem><para>If you are upgrading a running system, be on the lookout for -packages that use <command>cp</command> instead of <command>install</command> to -install files. The latter command is usually safer if the executable or library -is already loaded in memory.</para></listitem> -</itemizedlist> + <para>A Package Manager makes it easy to upgrade to newer versions when + they are released. Generally the instructions in the LFS and BLFS Book can be + used to upgrade to the newer versions. Here are some points that you should + be aware of when upgrading packages, especially on a running system.</para> -</sect2> + <itemizedlist> + <listitem> + <para>If one of the toolchain package (glibc, gcc, + binutils) needs to be upgraded to a newer minor vesion, it is safer to rebuild + LFS. Though you <emphasis>may</emphasis> be able to get by + rebuilding all the packages in their dependency order. We do not recommend it. + For example, if glibc-2.2.x needs to be updated to glibc-2.3.x, it is safer + to rebuild. For micro version updates, a simple reinstallation usually works, but + is not guaranteed. For example, upgrading from glibc-2.3.1 to glibc-2.3.2 will not + usually cause any problems.</para> + </listitem> + <listitem> + <para>If a package containing a shared library is updated, and if the + name of the library changes, then all the packages dynamically linked to the + library need to be recompiled to link against the newer library. (Note that there + is no corelation between the package version and the name of the library.) For + example, consider a package foo-1.2.3 that installs a shared library with name + <filename>libfoo.so.1</filename>. Say you upgrade the package to a newer version + foo-1.2.4 that installs a shared library with name <filename>libfoo.so.2</filename>. + In this case, all packages that are dynamically linked to <filename>libfoo.so.1</filename> + need to be recompiled to link against <filename>libfoo.so.2</filename>. Note that + you should not remove the previous libraries till the dependent packages are + recompiled.</para> + </listitem> + <listitem> + <para>If you are upgrading a running system, be on the lookout for packages + that use <command>cp</command> instead of <command>install</command> + to install files. The latter command is usually safer if the executable or library + is already loaded in memory.</para> + </listitem> + </itemizedlist> + </sect2> -<sect2> -<title>Package Management Techniques</title> + <sect2> + <title>Package Management Techniques</title> -<para>The following are some common package management techniques. Before -making a decision on a package manager, do a research on the various -techniques, particularly the drawbacks of the particular scheme.</para> + <para>The following are some common package management techniques. Before + making a decision on a package manager, do a research on the various + techniques, particularly the drawbacks of the particular scheme.</para> -<sect3> -<title>It is all in my head!</title> + <sect3> + <title>It is All in My Head!</title> -<para>Yes, this is a package management technique. Some folks do not find the -need for a package manager because they know the packages intimately and know -what files are installed by each package. Some users also do not need any -package management because they plan on rebuilding the entire system -when a package is changed.</para> + <para>Yes, this is a package management technique. Some folks do not find the + need for a package manager because they know the packages intimately and know + what files are installed by each package. Some users also do not need any + package management because they plan on rebuilding the entire system + when a package is changed.</para> -</sect3> + </sect3> -<sect3> -<title>Install in separate directories</title> + <sect3> + <title>Install in Separate Directories</title> -<para>This is a simplistic package management that does not need any extra package -to manage the installations. Each package is installed in a separate directory. -For example, package foo-1.1 is installed in <filename>/usr/pkg/foo-1.1</filename> -and a symlink is made from <filename>/usr/pkg/foo</filename> to -<filename>/usr/pkg/foo-1.1</filename>. When installing a new version foo-1.2, -it is installed in <filename>/usr/pkg/foo-1.2</filename> and the previous -symlink is replaced by a symlink to the new vesion.</para> + <para>This is a simplistic package management that does not need any extra package + to manage the installations. Each package is installed in a separate directory. + For example, package foo-1.1 is installed in <filename>/usr/pkg/foo-1.1</filename> + and a symlink is made from <filename>/usr/pkg/foo</filename> to + <filename>/usr/pkg/foo-1.1</filename>. When installing a new version foo-1.2, + it is installed in <filename>/usr/pkg/foo-1.2</filename> and the previous + symlink is replaced by a symlink to the new vesion.</para> -<para>The environment variables such as those -mentioned in <xref linkend="intro-important-beyond"/> need to be expanded to -include <filename>/usr/pkg/foo</filename>. For more than a few packages, -this scheme becomes unmanageable.</para> + <para>The environment variables such as those + mentioned in <xref linkend="intro-important-beyond"/> need to be expanded to + include <filename>/usr/pkg/foo</filename>. For more than a few packages, + this scheme becomes unmanageable.</para> -</sect3> + </sect3> -<sect3> -<title>Symlink style package management</title> + <sect3> + <title>Symlink Style Package Management</title> -<para>This is a variation of the previous package management technique. Each package -is installed similar to the previous scheme. But instead of making the symlink, -each file is symlinked into <filename>/usr</filename> hierarchy. This removes the need -to expand the environment variables. Though the symlinks can be created by the user, -to automate the creation, many package managers have been written on this approach. -A few of the popular ones are Stow, Epkg, Graft, and Depot.</para> + <para>This is a variation of the previous package management technique. Each package + is installed similar to the previous scheme. But instead of making the symlink, + each file is symlinked into <filename>/usr</filename> hierarchy. This removes the need + to expand the environment variables. Though the symlinks can be created by the user, + to automate the creation, many package managers have been written on this approach. + A few of the popular ones are Stow, Epkg, Graft, and Depot.</para> -<para>The installation needs to be faked, so that the package thinks that it is -installed in <filename class="directory">/usr</filename> though in reality it is installed in -<filename class="directory">/usr/pkg</filename> hierarchy. Installing in this manner is not usually a trivial -task. For example, consider that you are installing a package libfoo-1.1. The following -instructions may not install the package properly:</para> + <para>The installation needs to be faked, so that the package thinks that it is + installed in <filename class="directory">/usr</filename> though in reality it is + installed in <filename class="directory">/usr/pkg</filename> hierarchy. + Installing in this manner is not usually a trivial task. For example, consider + that you are installing a package libfoo-1.1. The following instructions may + not install the package properly:</para> -<screen><userinput><command>./configure --prefix=/usr/pkg/libfoo/1.1 +<screen><userinput>./configure --prefix=/usr/pkg/libfoo/1.1 make -make install</command></userinput></screen> +make install</userinput></screen> -<para>The installation will work, but the dependent packages may not link to -libfoo as you would expect. If you compile a package that links against libfoo, -you may notice that it is linked to <filename>/usr/pkg/libfoo/1.1/lib/libfoo.so.1</filename> -instead of <filename>/usr/lib/libfoo.so.1</filename> as you would expect. The correct -approach is to use <envar>DESTDIR</envar> strategy to fake installation of the package. -This approach works as follows:</para> + <para>The installation will work, but the dependent packages may not link to + libfoo as you would expect. If you compile a package that links against libfoo, + you may notice that it is linked to <filename>/usr/pkg/libfoo/1.1/lib/libfoo.so.1</filename> + instead of <filename>/usr/lib/libfoo.so.1</filename> as you would expect. The correct + approach is to use <envar>DESTDIR</envar> strategy to fake installation of the package. + This approach works as follows:</para> -<screen><userinput><command>./configure --prefix=/usr +<screen><userinput>./configure --prefix=/usr make -make DESTDIR=/usr/pkg/libfoo/1.1 install</command></userinput></screen> +make DESTDIR=/usr/pkg/libfoo/1.1 install</userinput></screen> -<para>Most of the packages do support this approach, but there are some which do not. -For the non-compliant packages, you may either need to manually install the package, -or you may find that it is easier to install some problematic packages into -<filename>/opt</filename>.</para> + <para>Most of the packages do support this approach, but there are some which do not. + For the non-compliant packages, you may either need to manually install the package, + or you may find that it is easier to install some problematic packages into + <filename>/opt</filename>.</para> -</sect3> + </sect3> -<sect3> -<title>Timestamp based</title> + <sect3> + <title>Timestamp Based</title> -<para>In this technique, a file is timestamped before the installation of the package. -After the installation, a simple use of the <command>find</command> command with the -appropriate options can generate a log of all the files installed after the timestamp -file was created. A package manager written with this approach is install-log.</para> + <para>In this technique, a file is timestamped before the installation of the package. + After the installation, a simple use of the <command>find</command> command with the + appropriate options can generate a log of all the files installed after the timestamp + file was created. A package manager written with this approach is install-log.</para> -<para>Though this scheme has the advantage of being simple, it has two drawbacks. -If during installation, the files are installed with any timestamp other than the -current time, those files will not be tracked by the package manager. Also, this -scheme can only be used when one package is installed at a time. The logs are not -reliable if two packages are being installed on two different consoles.</para> + <para>Though this scheme has the advantage of being simple, it has two drawbacks. + If during installation, the files are installed with any timestamp other than the + current time, those files will not be tracked by the package manager. Also, this + scheme can only be used when one package is installed at a time. The logs are not + reliable if two packages are being installed on two different consoles.</para> -</sect3> + </sect3> -<sect3> -<title>LD_PRELOAD based</title> + <sect3> + <title>LD_PRELOAD Based</title> -<para>In this approach, a library is preloaded before installation. During -installation, this library tracks the packages that are being installed by -attaching itself to various executables such as <command>cp</command>, -<command>install</command>, <command>mv</command> and tracking the system -calls that modify the filesystem. For this approach to work, all the executables -need to be dymanically linked without the suid or sgid bit. Preloading the -library may cause some unwanted side-effects during installation. Therefore, -do perform some tests to ensure that the package manager does not break -anything and logs all the appropriate files.</para> + <para>In this approach, a library is preloaded before installation. During + installation, this library tracks the packages that are being installed by + attaching itself to various executables such as <command>cp</command>, + <command>install</command>, <command>mv</command> and tracking the system + calls that modify the filesystem. For this approach to work, all the executables + need to be dymanically linked without the suid or sgid bit. Preloading the + library may cause some unwanted side-effects during installation. Therefore, + do perform some tests to ensure that the package manager does not break + anything and logs all the appropriate files.</para> -</sect3> + </sect3> -<sect3> -<title>Creating Package Archives</title> + <sect3> + <title>Creating Package Archives</title> -<para>In this scheme, the package installation is faked into a separate -tree as described in the Symlink style package management. After the -installation, a package archive is created using the installed files. -This archive is then used to install the package either on the local -machine or can even be used to install the package on other machines.</para> + <para>In this scheme, the package installation is faked into a separate + tree as described in the Symlink style package management. After the + installation, a package archive is created using the installed files. + This archive is then used to install the package either on the local + machine or can even be used to install the package on other machines.</para> -<para>This approach is used by most of the package managers found in the -commercial distributions. Examples of package managers that follow this -approach are RPM, pkg-utils, Debian's apt, and Gentoo's Portage system.</para> + <para>This approach is used by most of the package managers found in the + commercial distributions. Examples of package managers that follow this + approach are RPM, pkg-utils, Debian's apt, and Gentoo's Portage system.</para> -</sect3> + </sect3> -<sect3> -<title>User Based Management</title> + <sect3> + <title>User Based Management</title> -<para>This scheme, that is unique to <acronym>LFS</acronym>, was -devised by Matthias Benkmann, and is available from the <ulink -url="http://www.linuxfromscratch.org/hints/";>Hints Project</ulink>. -In this scheme, each package is installed as a separate user into -the standard locations. Files belonging to a package are easily -identified by checking the user id. The features and shortcomings -of this approach are too complex to describe in this section. For -the details please see the hint at <ulink -url="http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt"/>.</para> + <para>This scheme, that is unique to LFS, was devised by Matthias Benkmann, + and is available from the <ulink url="http://www.linuxfromscratch.org/hints/";>Hints + Project</ulink>. In this scheme, each package is installed as a separate user + into the standard locations. Files belonging to a package are easily identified + by checking the user id. The features and shortcomings of this approach are + too complex to describe in this section. For the details please see the hint at <ulink + url="http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt"/>.</para> -</sect3> + </sect3> -</sect2> + </sect2> - </sect1> -- http://linuxfromscratch.org/mailman/listinfo/blfs-book FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
