gronod/lfs
1
0
Fork 0
mirror of https://git.linuxfromscratch.org/lfs.git synced 2025-06-18 19:29:21 +01:00
Code Issues Packages Projects Releases Wiki Activity

Corrected grammatical errors and cleaned up English idiom.

Browse Source
This commit is contained in:
David Bryant 2022-10-01 17:03:20 -05:00
parent 2bf32ffa3a
commit 4349661a7f
1 changed files with 80 additions and 80 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

160
chapter08/pkgmgt.xml
View File

@ -11,13 +11,13 @@
<title>Package Management</title>
<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
Package Manager tracks the installation of files, making it easier to
remove and upgrade packages. As well as the binary and library files, a
package manager will handle the installation of configuration files. Before
you begin to wonder, NO&mdash;this section will not talk about nor recommend
any particular package manager. 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
be among these techniques, or it may be a combination of two or more of these
techniques. This section briefly mentions issues that may arise when upgrading
packages.</para>
@ -32,14 +32,14 @@
<listitem>
<para>There are multiple solutions for package management, each having
its strengths and drawbacks. Including one that satisfies all audiences
its strengths and drawbacks. Finding one solution that satisfies all audiences
is difficult.</para>
</listitem>
</itemizedlist>
<para>There are some hints written on the topic of package management. Visit
the <ulink url="&hints-root;">Hints Project</ulink> and see if one of them
fits your need.</para>
fits your needs.</para>
<sect2 id='pkgmgmt-upgrade-issues'>
<title>Upgrade Issues</title>
@ -51,18 +51,18 @@
<itemizedlist>
<listitem>
<para>If Linux kernel needs to be upgraded (for example, from
5.10.17 to 5.10.18 or 5.11.1), nothing else need to be rebuilt.
The system will keep working fine thanks to the well-defined border
between kernel and userspace. Specifically, Linux API headers
need not to be (and should not be, see the next item) upgraded
alongside the kernel. You'll need to reboot your system to use the
<para>If the Linux kernel needs to be upgraded (for example, from
5.10.17 to 5.10.18 or 5.11.1), nothing else needs to be rebuilt.
The system will keep working fine thanks to the well-defined interface
between the kernel and user space. Specifically, Linux API headers
need not be (and should not be, see the next item) upgraded
along with the kernel. You will merely need to reboot your system to use the
upgraded kernel.</para>
</listitem>
<listitem>
<para>If Linux API headers or Glibc needs to be upgraded to a newer
version, (e.g. from glibc-2.31 to glibc-2.32), it is safer to
<para>If Linux API headers or glibc need to be upgraded to a newer
version, (e.g., from glibc-2.31 to glibc-2.32), it is safer to
rebuild LFS. Though you <emphasis>may</emphasis> be able to rebuild
all the packages in their dependency order, we do not recommend
it. </para>
@ -70,44 +70,44 @@
<listitem> <para>If a package containing a shared library is updated, and
if the name of the library changes, then any packages dynamically
linked to the library need to be recompiled in order to link against the
linked to the library must be recompiled, to link against the
newer library. (Note that there is no correlation 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
class='libraryfile'>libfoo.so.1</filename>. If you upgrade the package to
a newer version foo-1.2.4 that installs a shared library with name
foo-1.2.3 that installs a shared library with the name <filename
class='libraryfile'>libfoo.so.1</filename>. Suppose you upgrade the package to
a newer version foo-1.2.4 that installs a shared library with the name
<filename class='libraryfile'>libfoo.so.2</filename>. In this case, any
packages that are dynamically linked to <filename
class='libraryfile'>libfoo.so.1</filename> need to be recompiled to link
against <filename class='libraryfile'>libfoo.so.2</filename> in order to
use the new library version. You should not remove the previous
libraries unless all the dependent packages are recompiled.</para>
use the new library version. You should not remove the old
libraries until all the dependent packages have been recompiled.</para>
</listitem>
<listitem> <para>If a package containing a shared library is updated,
and the name of library doesn't change, but the version number of the
and the name of the library doesn't change, but the version number of the
library <emphasis role="bold">file</emphasis> decreases (for example,
the name of the library is kept named
the library is still named
<filename class='libraryfile'>libfoo.so.1</filename>,
but the name of library file is changed from
but the name of the library file is changed from
<filename class='libraryfile'>libfoo.so.1.25</filename> to
<filename class='libraryfile'>libfoo.so.1.24</filename>),
you should remove the library file from the previously installed version
(<filename class='libraryfile'>libfoo.so.1.25</filename> in the case).
Or, a <command>ldconfig</command> run (by yourself using a command
(<filename class='libraryfile'>libfoo.so.1.25</filename> in this case).
Otherwise, a <command>ldconfig</command> command (invokeed by yourself from the command
line, or by the installation of some package) will reset the symlink
<filename class='libraryfile'>libfoo.so.1</filename> to point to
the old library file because it seems having a <quote>newer</quote>
version, as its version number is larger. This situation may happen if
you have to downgrade a package, or the package changes the versioning
scheme of library files suddenly.</para> </listitem>
the old library file because it seems to be a <quote>newer</quote>
version; its version number is larger. This situation may arise if
you have to downgrade a package, or if the authors change the versioning
scheme for library files.</para> </listitem>
<listitem><para>If a package containing a shared library is updated,
and the name of library doesn't change, but a severe issue
and the name of the library doesn't change, but a severe issue
(especially, a security vulnerability) is fixed, all running programs
linked to the shared library should be restarted. The following
command, run as <systemitem class="username">root</systemitem> after
updating, will list what is using the old versions of those libraries
the update is cmplete, will list which processes are using the old versions of those libraries
(replace <replaceable>libfoo</replaceable> with the name of the
library):</para>
@ -115,33 +115,33 @@
tr -cd 0-9\\n | xargs -r ps u</userinput></screen>
<para>
If <application>OpenSSH</application> is being used for accessing
the system and it is linked to the updated library, you need to
restart <command>sshd</command> service, then logout, login again,
and rerun that command to confirm nothing is still using the
If <application>OpenSSH</application> is being used to access
the system and it is linked to the updated library, you must
restart the <command>sshd</command> service, then logout, login again,
and rerun the preceding ps command to confirm that nothing is still using the
deleted libraries.
</para>
<para revision='systemd'>
If the <command>systemd</command> daemon (running as PID 1) is
linked to the updated library, you can restart it without reboot
linked to the updated library, you can restart it without rebooting
by running <command>systemctl daemon-reexec</command> as the
<systemitem class='username'>root</systemitem> user.
</para></listitem>
<listitem>
<para>If a binary or a shared library is overwritten, the processes
using the code or data in the binary or library may crash. The
correct way to update a binary or a shared library without causing
<para>If an executable program or a shared library is overwritten, the processes
using the code or data in that program or library may crash. The
correct way to update a program or a shared library without causing
the process to crash is to remove it first, then install the new
version into position. The <command>install</command> command
provided by <application>Coreutils</application> has already
implemented this and most packages use it to install binaries and
version. The <command>install</command> command
provided by <application>coreutils</application> has already
implemented this, and most packages use that command to install binary files and
libraries. This means that you won't be troubled by this issue most of the time.
However, the install process of some packages (notably Mozilla JS
in BLFS) just overwrites the file if it exists and causes a crash, so
in BLFS) just overwrites the file if it exists; this causes a crash. So
it's safer to save your work and close unneeded running processes
before updating a package.</para>
before updating a package.</para> <!-- binary is an adjective, not a noun. -->
</listitem>
</itemizedlist>
@ -152,36 +152,36 @@
<para>The following are some common package management techniques. Before
making a decision on a package manager, do some research on the various
techniques, particularly the drawbacks of the particular scheme.</para>
techniques, particularly the drawbacks of each particular scheme.</para>
<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
<para>Yes, this is a package management technique. Some folks do not
need a package manager because they know the packages intimately
and know which 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>
system whenever a package is changed.</para>
</sect3>
<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
<para>This is a simplistic package management technique that does not need a
special program to manage the packages. Each package is installed in a
separate directory. For example, package foo-1.1 is installed in
<filename class='directory'>/usr/pkg/foo-1.1</filename>
and a symlink is made from <filename>/usr/pkg/foo</filename> to
<filename class='directory'>/usr/pkg/foo-1.1</filename>. When installing
a new version foo-1.2, it is installed in
<filename class='directory'>/usr/pkg/foo-1.1</filename>. When
a new version foo-1.2 comes along, it is installed in
<filename class='directory'>/usr/pkg/foo-1.2</filename> and the previous
symlink is replaced by a symlink to the new version.</para>
<para>Environment variables such as <envar>PATH</envar>,
<envar>LD_LIBRARY_PATH</envar>, <envar>MANPATH</envar>,
<envar>INFOPATH</envar> and <envar>CPPFLAGS</envar> need to be expanded to
include <filename>/usr/pkg/foo</filename>. For more than a few packages,
include <filename>/usr/pkg/foo</filename>. If you install more than a few packages,
this scheme becomes unmanageable.</para>
</sect3>
@ -190,15 +190,15 @@
<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 the
Each package is installed as in the previous scheme. But instead of
making the symlink via a generic package name, each file is symlinked into the
<filename class='directory'>/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 using this approach. A few of the popular ones include Stow,
created by the user, many package managers use this approach, and
automate the creation of the symlinks. A few of the popular ones include Stow,
Epkg, Graft, and Depot.</para>
<para>The installation needs to be faked, so that the package thinks that
<para>The installation script needs to be fooled, so the package thinks
it is installed in <filename class="directory">/usr</filename> though in
reality it is installed in the
<filename class="directory">/usr/pkg</filename> hierarchy. Installing in
@ -216,7 +216,7 @@ make install</userinput></screen>
<filename class='libraryfile'>/usr/pkg/libfoo/1.1/lib/libfoo.so.1</filename>
instead of <filename class='libraryfile'>/usr/lib/libfoo.so.1</filename>
as you would expect. The correct approach is to use the
<envar>DESTDIR</envar> strategy to fake installation of the package. This
<envar>DESTDIR</envar> variable to direct the installation. This
approach works as follows:</para>
<screen role="nodump"><userinput>./configure --prefix=/usr
@ -224,8 +224,8 @@ make
make DESTDIR=/usr/pkg/libfoo/1.1 install</userinput></screen>
<para>Most packages 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
For the non-compliant packages, you may either need to install the
package manually, or you may find that it is easier to install some problematic
packages into <filename class='directory'>/opt</filename>.</para>
</sect3>
@ -237,14 +237,14 @@ make DESTDIR=/usr/pkg/libfoo/1.1 install</userinput></screen>
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>
package manager that uses 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>
the package manager. Also, this scheme can only be used when packages
are installed one at a time. The logs are not reliable if two packages are
installed simultaneously from two different consoles.</para>
</sect3>
@ -262,12 +262,12 @@ make DESTDIR=/usr/pkg/libfoo/1.1 install</userinput></screen>
calls that modify the filesystem. For this approach to work, all the
executables need to be dynamically linked without the suid or sgid bit.
Preloading the library may cause some unwanted side-effects during
installation. Therefore, it is advised that one performs some tests to
ensure that the package manager does not break anything and logs all the
installation. Therefore, it's a good idea to perform some tests to
ensure that the package manager does not break anything, and that it logs all the
appropriate files.</para>
<para>The second technique is to use <command>strace</command>, which
logs all system calls made during the execution of the installation
<para>Another technique is to use <command>strace</command>, which
logs all the system calls made during the execution of the installation
scripts.</para>
</sect3>
@ -275,10 +275,10 @@ make DESTDIR=/usr/pkg/libfoo/1.1 install</userinput></screen>
<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
tree as previously described in the symlink style package management section. 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>
This archive is then used to install the package on the local
machine or even 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
@ -289,10 +289,10 @@ make DESTDIR=/usr/pkg/libfoo/1.1 install</userinput></screen>
package management for LFS systems is located at <ulink
url="&hints-root;fakeroot.txt"/>.</para>
<para>Creation of package files that include dependency information is
complex and is beyond the scope of LFS.</para>
<para>The creation of package files that include dependency information is
complex, and beyond the scope of LFS.</para>
<para>Slackware uses a <command>tar</command> based system for package
<para>Slackware uses a <command>tar</command>-based system for package
archives. This system purposely does not handle package dependencies
as more complex package managers do. For details of Slackware package
management, see <ulink
@ -322,8 +322,8 @@ make DESTDIR=/usr/pkg/libfoo/1.1 install</userinput></screen>
another computer with the same architecture as the base system is as
simple as using <command>tar</command> on the LFS partition that contains
the root directory (about 250MB uncompressed for a base LFS build), copying
that file via network transfer or CD-ROM to the new system and expanding
it. From that point, a few configuration files will have to be changed.
that file via network transfer or CD-ROM / USB stick to the new system, and expanding
it. After that, a few configuration files will have to be changed.
Configuration files that may need to be updated include:
<filename>/etc/hosts</filename>,
<filename>/etc/fstab</filename>,
@ -342,17 +342,17 @@ make DESTDIR=/usr/pkg/libfoo/1.1 install</userinput></screen>
</phrase>
</para>
<para>A custom kernel may need to be built for the new system depending on
<para>A custom kernel may be needed for the new system, depending on
differences in system hardware and the original kernel
configuration.</para>
<note><para>There have been some reports of issues when copying between
similar but not identical architectures. For instance, the instruction set
for an Intel system is not identical with an AMD processor and later
versions of some processors may have instructions that are unavailable in
for an Intel system is not identical with the AMD processor's instructions, and later
versions of some processors may provide instructions that are unavailable with
earlier versions.</para></note>
<para>Finally the new system has to be made bootable via <xref
<para>Finally, the new system has to be made bootable via <xref
linkend="ch-bootable-grub"/>.</para>
</sect2>