- Timestamp:
- 10/02/2022 01:49:39 PM (2 years ago)
- Branches:
- xry111/arm64, xry111/arm64-12.0
- Children:
- 1dcfd50
- Parents:
- 111194c (diff), 6582ddc5 (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the(diff)
links above to see all the changes relative to each parent. - Location:
- chapter08
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
chapter08/autoconf.xml
r111194c r96323bd 41 41 <sect2 role="installation"> 42 42 <title>Installation of Autoconf</title> 43 <!--44 <para>First, apply a patch fixes several problems that occur with the latest45 perl, libtool, and bash versions.</para>46 43 47 <screen><userinput remap="pre">patch -Np1 -i ../&autoconf-fixes-patch;</userinput></screen> 48 --> 44 <para>First, fix several problems with the tests caused by bash-5.2 and later:</para> 45 46 <screen><userinput remap="pre">sed -e 's/SECONDS|/&SHLVL|/' \ 47 -e '/BASH_ARGV=/a\ /^SHLVL=/ d' \ 48 -i.orig tests/local.at</userinput></screen> 49 49 50 <para>Prepare Autoconf for compilation:</para> 50 51 -
chapter08/pkgmgt.xml
r111194c r96323bd 12 12 13 13 <para>Package Management is an often requested addition to the LFS Book. A 14 Package Manager allows tracking the installation of files making it easyto14 Package Manager tracks the installation of files, making it easier to 15 15 remove and upgrade packages. As well as the binary and library files, a 16 16 package manager will handle the installation of configuration files. Before … … 18 18 any particular package manager. What it provides is a roundup of the more 19 19 popular techniques and how they work. The perfect package manager for you may 20 be among these techniques ormay be a combination of two or more of these20 be among these techniques, or it may be a combination of two or more of these 21 21 techniques. This section briefly mentions issues that may arise when upgrading 22 22 packages.</para> … … 33 33 <listitem> 34 34 <para>There are multiple solutions for package management, each having 35 its strengths and drawbacks. Including onethat satisfies all audiences35 its strengths and drawbacks. Finding one solution that satisfies all audiences 36 36 is difficult.</para> 37 37 </listitem> … … 40 40 <para>There are some hints written on the topic of package management. Visit 41 41 the <ulink url="&hints-root;">Hints Project</ulink> and see if one of them 42 fits your need .</para>42 fits your needs.</para> 43 43 44 44 <sect2 id='pkgmgmt-upgrade-issues'> … … 52 52 <itemizedlist> 53 53 <listitem> 54 <para>If Linux kernel needs to be upgraded (for example, from55 5.10.17 to 5.10.18 or 5.11.1), nothing else need to be rebuilt.56 The system will keep working fine thanks to the well-defined border57 between kernel and userspace. Specifically, Linux API headers58 need not tobe (and should not be, see the next item) upgraded59 along side the kernel. You'llneed to reboot your system to use the54 <para>If the Linux kernel needs to be upgraded (for example, from 55 5.10.17 to 5.10.18 or 5.11.1), nothing else needs to be rebuilt. 56 The system will keep working fine thanks to the well-defined interface 57 between the kernel and user space. Specifically, Linux API headers 58 need not be (and should not be, see the next item) upgraded 59 along with the kernel. You will merely need to reboot your system to use the 60 60 upgraded kernel.</para> 61 61 </listitem> 62 62 63 63 <listitem> 64 <para>If Linux API headers or Glibc needsto be upgraded to a newer65 version, (e.g. from glibc-2.31 to glibc-2.32), it is safer to64 <para>If Linux API headers or glibc need to be upgraded to a newer 65 version, (e.g., from glibc-2.31 to glibc-2.32), it is safer to 66 66 rebuild LFS. Though you <emphasis>may</emphasis> be able to rebuild 67 67 all the packages in their dependency order, we do not recommend … … 71 71 <listitem> <para>If a package containing a shared library is updated, and 72 72 if the name of the library changes, then any packages dynamically 73 linked to the library need to be recompiled in orderto link against the73 linked to the library must be recompiled, to link against the 74 74 newer library. (Note that there is no correlation between the package 75 75 version and the name of the library.) For example, consider a package 76 foo-1.2.3 that installs a shared library with name <filename77 class='libraryfile'>libfoo.so.1</filename>. Ifyou upgrade the package to78 a newer version foo-1.2.4 that installs a shared library with name76 foo-1.2.3 that installs a shared library with the name <filename 77 class='libraryfile'>libfoo.so.1</filename>. Suppose you upgrade the package to 78 a newer version foo-1.2.4 that installs a shared library with the name 79 79 <filename class='libraryfile'>libfoo.so.2</filename>. In this case, any 80 80 packages that are dynamically linked to <filename 81 81 class='libraryfile'>libfoo.so.1</filename> need to be recompiled to link 82 82 against <filename class='libraryfile'>libfoo.so.2</filename> in order to 83 use the new library version. You should not remove the previous84 libraries un less all the dependent packages arerecompiled.</para>83 use the new library version. You should not remove the old 84 libraries until all the dependent packages have been recompiled.</para> 85 85 </listitem> 86 86 87 87 <listitem> <para>If a package containing a shared library is updated, 88 and the name of library doesn't change, but the version number of the88 and the name of the library doesn't change, but the version number of the 89 89 library <emphasis role="bold">file</emphasis> decreases (for example, 90 the name of the library is keptnamed90 the library is still named 91 91 <filename class='libraryfile'>libfoo.so.1</filename>, 92 but the name of library file is changed from92 but the name of the library file is changed from 93 93 <filename class='libraryfile'>libfoo.so.1.25</filename> to 94 94 <filename class='libraryfile'>libfoo.so.1.24</filename>), 95 95 you should remove the library file from the previously installed version 96 (<filename class='libraryfile'>libfoo.so.1.25</filename> in th ecase).97 O r, a <command>ldconfig</command> run (by yourself using acommand96 (<filename class='libraryfile'>libfoo.so.1.25</filename> in this case). 97 Otherwise, a <command>ldconfig</command> command (invoked by yourself from the command 98 98 line, or by the installation of some package) will reset the symlink 99 99 <filename class='libraryfile'>libfoo.so.1</filename> to point to 100 the old library file because it seems havinga <quote>newer</quote>101 version , as its version number is larger. This situation may happenif102 you have to downgrade a package, or the package changesthe versioning103 scheme of library files suddenly.</para> </listitem>100 the old library file because it seems to be a <quote>newer</quote> 101 version; its version number is larger. This situation may arise if 102 you have to downgrade a package, or if the authors change the versioning 103 scheme for library files.</para> </listitem> 104 104 105 105 <listitem><para>If a package containing a shared library is updated, 106 and the name of library doesn't change, but a severe issue106 and the name of the library doesn't change, but a severe issue 107 107 (especially, a security vulnerability) is fixed, all running programs 108 108 linked to the shared library should be restarted. The following 109 109 command, run as <systemitem class="username">root</systemitem> after 110 updating, will list what isusing the old versions of those libraries110 the update is complete, will list which processes are using the old versions of those libraries 111 111 (replace <replaceable>libfoo</replaceable> with the name of the 112 112 library):</para> … … 116 116 117 117 <para> 118 If <application>OpenSSH</application> is being used for accessing119 the system and it is linked to the updated library, you need to120 restart <command>sshd</command> service, then logout, login again,121 and rerun th at command to confirmnothing is still using the118 If <application>OpenSSH</application> is being used to access 119 the system and it is linked to the updated library, you must 120 restart the <command>sshd</command> service, then logout, login again, 121 and rerun the preceding ps command to confirm that nothing is still using the 122 122 deleted libraries. 123 123 </para> … … 125 125 <para revision='systemd'> 126 126 If the <command>systemd</command> daemon (running as PID 1) is 127 linked to the updated library, you can restart it without reboot 127 linked to the updated library, you can restart it without rebooting 128 128 by running <command>systemctl daemon-reexec</command> as the 129 129 <systemitem class='username'>root</systemitem> user. … … 131 131 132 132 <listitem> 133 <para>If a binaryor a shared library is overwritten, the processes134 using the code or data in th e binaryor library may crash. The135 correct way to update a binaryor a shared library without causing133 <para>If an executable program or a shared library is overwritten, the processes 134 using the code or data in that program or library may crash. The 135 correct way to update a program or a shared library without causing 136 136 the process to crash is to remove it first, then install the new 137 version into position. The <command>install</command> command138 provided by <application> Coreutils</application> has already139 implemented this and most packages use it to install binaries and137 version. The <command>install</command> command 138 provided by <application>coreutils</application> has already 139 implemented this, and most packages use that command to install binary files and 140 140 libraries. This means that you won't be troubled by this issue most of the time. 141 141 However, the install process of some packages (notably Mozilla JS 142 in BLFS) just overwrites the file if it exists and causes a crash, so142 in BLFS) just overwrites the file if it exists; this causes a crash. So 143 143 it's safer to save your work and close unneeded running processes 144 before updating a package.</para> 144 before updating a package.</para> <!-- binary is an adjective, not a noun. --> 145 145 </listitem> 146 146 </itemizedlist> … … 153 153 <para>The following are some common package management techniques. Before 154 154 making a decision on a package manager, do some research on the various 155 techniques, particularly the drawbacks of theparticular scheme.</para>155 techniques, particularly the drawbacks of each particular scheme.</para> 156 156 157 157 <sect3> 158 158 <title>It is All in My Head!</title> 159 159 160 <para>Yes, this is a package management technique. Some folks do not find161 the need fora package manager because they know the packages intimately162 and know wh atfiles are installed by each package. Some users also do not160 <para>Yes, this is a package management technique. Some folks do not 161 need a package manager because they know the packages intimately 162 and know which files are installed by each package. Some users also do not 163 163 need any package management because they plan on rebuilding the entire 164 system when a package is changed.</para>164 system whenever a package is changed.</para> 165 165 166 166 </sect3> … … 169 169 <title>Install in Separate Directories</title> 170 170 171 <para>This is a simplistic package management t hat does not need any extra172 package to manage the installations. Each package is installed in a171 <para>This is a simplistic package management technique that does not need a 172 special program to manage the packages. Each package is installed in a 173 173 separate directory. For example, package foo-1.1 is installed in 174 174 <filename class='directory'>/usr/pkg/foo-1.1</filename> 175 175 and a symlink is made from <filename>/usr/pkg/foo</filename> to 176 <filename class='directory'>/usr/pkg/foo-1.1</filename>. When installing177 a new version foo-1.2 , it is installed in176 <filename class='directory'>/usr/pkg/foo-1.1</filename>. When 177 a new version foo-1.2 comes along, it is installed in 178 178 <filename class='directory'>/usr/pkg/foo-1.2</filename> and the previous 179 179 symlink is replaced by a symlink to the new version.</para> … … 182 182 <envar>LD_LIBRARY_PATH</envar>, <envar>MANPATH</envar>, 183 183 <envar>INFOPATH</envar> and <envar>CPPFLAGS</envar> need to be expanded to 184 include <filename>/usr/pkg/foo</filename>. Formore than a few packages,184 include <filename>/usr/pkg/foo</filename>. If you install more than a few packages, 185 185 this scheme becomes unmanageable.</para> 186 186 … … 191 191 192 192 <para>This is a variation of the previous package management technique. 193 Each package is installed similar tothe previous scheme. But instead of194 making the symlink , each file is symlinked into the193 Each package is installed as in the previous scheme. But instead of 194 making the symlink via a generic package name, each file is symlinked into the 195 195 <filename class='directory'>/usr</filename> hierarchy. This removes the 196 196 need to expand the environment variables. Though the symlinks can be 197 created by the user to automate the creation, many package managers have198 been written using this approach. A few of the popular ones include Stow,197 created by the user, many package managers use this approach, and 198 automate the creation of the symlinks. A few of the popular ones include Stow, 199 199 Epkg, Graft, and Depot.</para> 200 200 201 <para>The installation needs to be faked, so that the package thinks that201 <para>The installation script needs to be fooled, so the package thinks 202 202 it is installed in <filename class="directory">/usr</filename> though in 203 203 reality it is installed in the … … 217 217 instead of <filename class='libraryfile'>/usr/lib/libfoo.so.1</filename> 218 218 as you would expect. The correct approach is to use the 219 <envar>DESTDIR</envar> strategy to fake installation of the package. This219 <envar>DESTDIR</envar> variable to direct the installation. This 220 220 approach works as follows:</para> 221 221 … … 225 225 226 226 <para>Most packages support this approach, but there are some which do not. 227 For the non-compliant packages, you may either need to manuallyinstall the228 package , or you may find that it is easier to install some problematic227 For the non-compliant packages, you may either need to install the 228 package manually, or you may find that it is easier to install some problematic 229 229 packages into <filename class='directory'>/opt</filename>.</para> 230 230 … … 238 238 <command>find</command> command with the appropriate options can generate 239 239 a log of all the files installed after the timestamp file was created. A 240 package manager written withthis approach is install-log.</para>240 package manager that uses this approach is install-log.</para> 241 241 242 242 <para>Though this scheme has the advantage of being simple, it has two 243 243 drawbacks. If, during installation, the files are installed with any 244 244 timestamp other than the current time, those files will not be tracked by 245 the package manager. Also, this scheme can only be used when one package246 is installedat a time. The logs are not reliable if two packages are247 being installed ontwo different consoles.</para>245 the package manager. Also, this scheme can only be used when packages 246 are installed one at a time. The logs are not reliable if two packages are 247 installed simultaneously from two different consoles.</para> 248 248 249 249 </sect3> … … 263 263 executables need to be dynamically linked without the suid or sgid bit. 264 264 Preloading the library may cause some unwanted side-effects during 265 installation. Therefore, it is advised that one performssome tests to266 ensure that the package manager does not break anything andlogs all the265 installation. Therefore, it's a good idea to perform some tests to 266 ensure that the package manager does not break anything, and that it logs all the 267 267 appropriate files.</para> 268 268 269 <para> The secondtechnique is to use <command>strace</command>, which270 logs all system calls made during the execution of the installation269 <para>Another technique is to use <command>strace</command>, which 270 logs all the system calls made during the execution of the installation 271 271 scripts.</para> 272 272 </sect3> … … 276 276 277 277 <para>In this scheme, the package installation is faked into a separate 278 tree as described in the Symlink style package management. After the278 tree as previously described in the symlink style package management section. After the 279 279 installation, a package archive is created using the installed files. 280 This archive is then used to install the package eitheron the local281 machine or can even be used to install the packageon other machines.</para>280 This archive is then used to install the package on the local 281 machine or even on other machines.</para> 282 282 283 283 <para>This approach is used by most of the package managers found in the … … 290 290 url="&hints-root;fakeroot.txt"/>.</para> 291 291 292 <para> Creation of package files that include dependency information is293 complex and isbeyond the scope of LFS.</para>294 295 <para>Slackware uses a <command>tar</command> 292 <para>The creation of package files that include dependency information is 293 complex, and beyond the scope of LFS.</para> 294 295 <para>Slackware uses a <command>tar</command>-based system for package 296 296 archives. This system purposely does not handle package dependencies 297 297 as more complex package managers do. For details of Slackware package … … 323 323 simple as using <command>tar</command> on the LFS partition that contains 324 324 the root directory (about 250MB uncompressed for a base LFS build), copying 325 that file via network transfer or CD-ROM to the new systemand expanding326 it. From that point, a few configuration files will have to be changed.325 that file via network transfer or CD-ROM / USB stick to the new system, and expanding 326 it. After that, a few configuration files will have to be changed. 327 327 Configuration files that may need to be updated include: 328 328 <filename>/etc/hosts</filename>, … … 343 343 </para> 344 344 345 <para>A custom kernel may need to be built for the new systemdepending on345 <para>A custom kernel may be needed for the new system, depending on 346 346 differences in system hardware and the original kernel 347 347 configuration.</para> … … 349 349 <note><para>There have been some reports of issues when copying between 350 350 similar but not identical architectures. For instance, the instruction set 351 for an Intel system is not identical with an AMD processorand later352 versions of some processors may have instructions that are unavailable in351 for an Intel system is not identical with the AMD processor's instructions, and later 352 versions of some processors may provide instructions that are unavailable with 353 353 earlier versions.</para></note> 354 354 355 <para>Finally the new system has to be made bootable via <xref355 <para>Finally, the new system has to be made bootable via <xref 356 356 linkend="ch-bootable-grub"/>.</para> 357 357
Note:
See TracChangeset
for help on using the changeset viewer.