2022-06-14 22:56:39 +03:00
|
|
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|
|
|
|
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
|
|
|
|
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
|
|
|
|
|
<!ENTITY % general-entities SYSTEM "../general.ent">
|
|
|
|
|
%general-entities;
|
|
|
|
|
]>
|
|
|
|
|
|
|
|
|
|
<sect1 id="ch-system-pkgmgt">
|
|
|
|
|
<?dbhtml filename="pkgmgt.html"?>
|
|
|
|
|
|
|
|
|
|
<title>Управление пакетами</title>
|
|
|
|
|
|
2023-07-12 21:03:43 +03:00
|
|
|
|
<para>Управление пакетами — часто cпрашиваемое дополнение к книге LFS. Менеджер
|
|
|
|
|
пакетов позволяет отслеживать установку файлов, упрощая удаление и обновление
|
|
|
|
|
пакетов. Хороший менеджер пакетов также будет обрабатывать конфигурационные файлы,
|
|
|
|
|
чтобы сохранить пользовательские настройки при переустановке или обновлении пакета.
|
|
|
|
|
Прежде чем вы начнете задаваться вопросом, НЕТ—в этом разделе не будет ни
|
|
|
|
|
говориться, ни рекомендоваться какой-либо конкретный менеджер пакетов. Что он
|
|
|
|
|
действительно предоставляет, так это обзор наиболее популярных методов и того,
|
|
|
|
|
как они работают. Идеальным менеджером пакетов для вас может быть один из этих
|
|
|
|
|
методов или комбинация двух и более методов. В этом разделе кратко упоминаются
|
|
|
|
|
проблемы, которые могут возникнуть при обновлении пакетов.</para>
|
2022-06-14 22:56:39 +03:00
|
|
|
|
|
|
|
|
|
<para>Некоторые причины, по которым менеджер пакетов не упоминается в LFS или BLFS
|
|
|
|
|
представлены ниже:</para>
|
|
|
|
|
|
|
|
|
|
<itemizedlist>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>Рассмотрение управления пакетами отвлекает внимание от целей этих
|
2023-07-12 21:03:43 +03:00
|
|
|
|
книг—обучения тому, как строится система Linux.</para>
|
2022-06-14 22:56:39 +03:00
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>Существует множество решений для управления пакетами, каждое из
|
|
|
|
|
которых имеет свои сильные и слабые стороны. Трудно найти такое,
|
2023-07-12 21:03:43 +03:00
|
|
|
|
которое удовлетворит всех.</para>
|
2022-06-14 22:56:39 +03:00
|
|
|
|
</listitem>
|
|
|
|
|
</itemizedlist>
|
|
|
|
|
|
|
|
|
|
<para>Есть несколько советов, написанных на тему управления пакетами. Посетите
|
|
|
|
|
проект <ulink url="&hints-root;">Советы</ulink> возможно вы найдете решение,
|
|
|
|
|
которое соответствует вашим потребностям.</para>
|
|
|
|
|
|
|
|
|
|
<sect2 id='pkgmgmt-upgrade-issues'>
|
|
|
|
|
<title>Проблемы с обновлением</title>
|
|
|
|
|
|
|
|
|
|
<para>Менеджер пакетов упрощает обновление до более новых версий после их
|
|
|
|
|
выпуска. Как правило, инструкции в книгах LFS и BLFS можно использовать для
|
|
|
|
|
обновления до более новых версий. Вот некоторые моменты, о которых следует
|
|
|
|
|
помнить при обновлении пакетов, особенно в работающей системе.</para>
|
|
|
|
|
|
|
|
|
|
<itemizedlist>
|
|
|
|
|
<listitem>
|
2023-05-26 00:07:20 +03:00
|
|
|
|
<para>Если нужно обновить ядро Linux (например, с 5.10.17 до 5.10.18 или
|
2022-06-14 22:56:39 +03:00
|
|
|
|
5.11.1), дополнительно пересобирать ничего не нужно. Система продолжит
|
|
|
|
|
нормально работать благодаря четко определенной границе между ядром и
|
|
|
|
|
пользовательским пространством. В частности, заголовки Linux API не нужно
|
2024-02-03 21:49:11 +03:00
|
|
|
|
обновлять вместе с ядром. Вам просто нужно перезагрузить систему, чтобы
|
|
|
|
|
использовать обновленное ядро.</para>
|
2022-06-14 22:56:39 +03:00
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
2024-02-06 12:42:52 +03:00
|
|
|
|
<para>Если необходимо обновить Glibc до более новой версии (например, с Glibc-2.36
|
|
|
|
|
до Glibc-&glibc-version;) необходимо выполнить некоторые дополнительные действия,
|
|
|
|
|
чтобы избежать поломки системы. Подробности читайте в <xref linkend='ch-system-glibc'/>.</para>
|
2023-10-05 17:49:15 +03:00
|
|
|
|
</listitem>
|
|
|
|
|
|
2022-06-14 22:56:39 +03:00
|
|
|
|
<listitem> <para>Если пакет, содержащий общую библиотеку, обновляется и имя
|
|
|
|
|
библиотеки изменилось, то любые пакеты, динамически связанные с библиотекой,
|
|
|
|
|
необходимо перекомпилировать, чтобы связать с более новой библиотекой.
|
|
|
|
|
(Обратите внимание, что между версией пакета и именем библиотеки нет никакой
|
|
|
|
|
связи.) Например, рассмотрим пакет foo-1.2.3, который устанавливает общую
|
|
|
|
|
библиотеку с именем <filename class='libraryfile'>libfoo.so.1</filename>.
|
2023-07-12 21:03:43 +03:00
|
|
|
|
Предположим, вы обновили пакет до более новой версии foo-1.2.4, которая устанавливает
|
2022-06-14 22:56:39 +03:00
|
|
|
|
общую библиотеку с именем <filename class='libraryfile'>libfoo.so.2</filename>,
|
|
|
|
|
все пакеты, которые динамически связаны с <filename class='libraryfile'>libfoo.so.1</filename>,
|
|
|
|
|
должны быть перекомпилированы для связи с <filename class='libraryfile'>libfoo.so.2</filename>,
|
2023-07-12 21:03:43 +03:00
|
|
|
|
чтобы использовать новую версию библиотеки. Вы не должны удалять старые
|
2022-06-14 22:56:39 +03:00
|
|
|
|
библиотеки, пока все зависимые пакеты не будут перекомпилированы.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
|
2023-09-01 21:38:19 +03:00
|
|
|
|
<listitem><para>Если пакет (прямо или косвенно) связан как со старым, так и
|
|
|
|
|
с новым именем общей библиотеки (например, пакет ссылается как на
|
|
|
|
|
<filename class='libraryfile'>libfoo.so.2</filename>, так и на
|
2023-09-02 00:28:17 +03:00
|
|
|
|
<filename class='libraryfile'>libbar.so.1</filename>, в то время как последний
|
2023-09-01 21:38:19 +03:00
|
|
|
|
ссылается на <filename class='libraryfile'>libfoo.so.3</filename>), пакет может
|
|
|
|
|
работать неправильно, поскольку разные версии общей библиотеки содержат несовместимые
|
|
|
|
|
определения для некоторых имен символов. Это может быть вызвано перекомпиляцией
|
|
|
|
|
некоторых, но не всех, пакетов, связанных со старой общей библиотекой, после
|
|
|
|
|
обновления пакета, предоставляющего общую библиотеку. Чтобы избежать этой проблемы,
|
|
|
|
|
пользователям необходимо как можно скорее пересобрать каждый пакет, связанный с
|
|
|
|
|
общей библиотекой, с обновленной версией (например, с libfoo.so.2 на libfoo.so.3).
|
|
|
|
|
</para></listitem>
|
|
|
|
|
|
2022-06-14 22:56:39 +03:00
|
|
|
|
<listitem> <para>Если пакет, содержащий общую библиотеку, обновляется, а имя
|
|
|
|
|
библиотеки не меняется, но уменьшается номер версии <emphasis role="bold">файла</emphasis>
|
2023-07-12 21:03:43 +03:00
|
|
|
|
библиотеки (например, библиотека по-прежнему называется
|
2022-06-14 22:56:39 +03:00
|
|
|
|
<filename class='libraryfile'>libfoo.so.1</filename>, но имя файла библиотеки изменилось с
|
|
|
|
|
<filename class='libraryfile'>libfoo.so.1.25</filename> на
|
|
|
|
|
<filename class='libraryfile'>libfoo.so.1.24</filename>), следует удалить файл
|
2023-07-12 21:03:43 +03:00
|
|
|
|
библиотеки ранее установленной версии (в данном случае
|
|
|
|
|
<filename class='libraryfile'>libfoo.so.1.25</filename>). В противном случае, команда
|
|
|
|
|
<command>ldconfig</command> (запущенная самостоятельно с помощью командной строки или
|
|
|
|
|
при установке какого-либо пакета) приведёт к сбросу символической ссылки
|
|
|
|
|
<filename class='libraryfile'>libfoo.so.1</filename>,
|
|
|
|
|
которая будет указывать на старый файл библиотеки, потому что кажется, что она имеет
|
|
|
|
|
<quote>более новую</quote> версию, поскольку её номер версии больше. Такая ситуация
|
|
|
|
|
может произойти, если вам нужно понизить версию пакета или авторы изменили
|
2022-06-14 22:56:39 +03:00
|
|
|
|
схему управления версиями файлов библиотеки.</para></listitem>
|
|
|
|
|
|
|
|
|
|
<listitem><para>Если пакет, содержащий общую библиотеку, обновляется, а имя библиотеки
|
|
|
|
|
не меняется, но устраняется серьезная проблема (особенно уязвимость в системе безопасности),
|
|
|
|
|
необходимо перезапустить все работающие программы, связанные с общей библиотекой. Следующая
|
|
|
|
|
команда, запущенная от имени пользователя <systemitem class="username">root</systemitem> после
|
2023-07-12 21:03:43 +03:00
|
|
|
|
завершения обновления, выведет список программ, которые использует старые версии этих библиотек
|
2022-06-14 22:56:39 +03:00
|
|
|
|
(замените <replaceable>libfoo</replaceable> именем библиотеки):</para>
|
|
|
|
|
|
2023-09-01 21:38:19 +03:00
|
|
|
|
<screen role="nodump"><userinput>grep -l '<replaceable>libfoo</replaceable>.*deleted' /proc/*/maps | tr -cd 0-9\\n | xargs -r ps u</userinput></screen>
|
2022-06-14 22:56:39 +03:00
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Если для доступа к системе используется <application>OpenSSH</application> и он
|
|
|
|
|
связан с обновленной библиотекой, вам необходимо перезапустить службу
|
|
|
|
|
<command>sshd</command>, затем выйти из системы, снова войти в систему и повторно
|
2023-09-01 21:38:19 +03:00
|
|
|
|
выполнить предыдущую команду, чтобы убедиться, что удаленные библиотеки более
|
2023-07-12 21:03:43 +03:00
|
|
|
|
не используются.
|
2022-06-14 22:56:39 +03:00
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para revision='systemd'>
|
|
|
|
|
Если демон <command>systemd</command> (работающий как PID 1) связан с обновленной
|
|
|
|
|
библиотекой, вы можете перезапустить его без перезагрузки, запустив
|
|
|
|
|
<command>systemctl daemon-reexec</command> от имени пользователя
|
|
|
|
|
<systemitem class='username'>root</systemitem>.
|
|
|
|
|
</para></listitem>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
2023-07-12 21:03:43 +03:00
|
|
|
|
<para>Если исполняемая программа или библиотека перезаписаны, процессы, использующие
|
|
|
|
|
код или данные из них, могут завершиться сбоем. Правильный способ обновить программу
|
|
|
|
|
или общую библиотеку, не вызывая сбоя процесса, - это сначала удалить его,
|
2022-06-14 22:56:39 +03:00
|
|
|
|
а затем установить новую версию. Команда <command>install</command>,
|
|
|
|
|
предоставляемая <application>Coreutils</application>, уже реализовала это, и
|
2023-07-12 21:03:43 +03:00
|
|
|
|
большинство пакетов используют ее для установки двоичных файлов и библиотек.
|
2022-06-14 22:56:39 +03:00
|
|
|
|
Это означает, что большую часть времени вас не будет беспокоить эта проблема.
|
2023-11-01 20:03:09 +03:00
|
|
|
|
Однако процесс установки некоторых пакетов (в частности, SpiderMonkey в BLFS)
|
2023-07-12 21:03:43 +03:00
|
|
|
|
просто перезаписывает файл, если он существует, и вызывает сбой. Поэтому
|
|
|
|
|
безопаснее сохранить свою работу и закрыть ненужные запущенные программы перед
|
2022-06-14 22:56:39 +03:00
|
|
|
|
обновлением пакета.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</itemizedlist>
|
|
|
|
|
|
|
|
|
|
</sect2>
|
|
|
|
|
|
|
|
|
|
<sect2>
|
|
|
|
|
<title>Методы управления пакетами</title>
|
|
|
|
|
|
|
|
|
|
<para>Ниже приведены некоторые распространенные методы управления пакетами. Прежде
|
2023-07-12 21:03:43 +03:00
|
|
|
|
чем принять решение о менеджере пакетов, проведите исследование различных методов,
|
|
|
|
|
особенно недостатки каждой конкретной схемы.</para>
|
2022-06-14 22:56:39 +03:00
|
|
|
|
|
|
|
|
|
<sect3>
|
|
|
|
|
<title>Всё у меня в голове!</title>
|
|
|
|
|
|
|
|
|
|
<para>Да, это метод управления пакетами. Некоторым людям не нужен менеджер пакетов,
|
|
|
|
|
потому что они хорошо знакомы с пакетами и знают, какие файлы устанавливаются
|
|
|
|
|
каждым пакетом. Некоторым пользователям также не требуется какое-либо управление
|
2023-07-12 21:03:43 +03:00
|
|
|
|
пакетами, поскольку они планируют пересобирать всю систему при каждом изменении пакета.</para>
|
2022-06-14 22:56:39 +03:00
|
|
|
|
|
|
|
|
|
</sect3>
|
|
|
|
|
|
|
|
|
|
<sect3>
|
|
|
|
|
<title>Установка в отдельные каталоги</title>
|
|
|
|
|
|
2023-07-12 21:03:43 +03:00
|
|
|
|
<para>Это упрощенный метод управления пакетами, для которого не требуется
|
2023-11-09 20:26:01 +03:00
|
|
|
|
специальная программа управления. Каждый пакет устанавливается в отдельный
|
2022-06-14 22:56:39 +03:00
|
|
|
|
каталог. Например, пакет foo-1.1 устанавливается в
|
2023-11-09 20:26:01 +03:00
|
|
|
|
<filename class='directory'>/opt/foo-1.1</filename>, а символическая ссылка
|
|
|
|
|
создается из <filename>/opt/foo</filename> в
|
|
|
|
|
<filename class='directory'>/opt/foo-1.1</filename>. Когда появляется новая
|
|
|
|
|
версия foo-1.2, она устанавливается в <filename class='directory'>/opt/foo-1.2</filename>
|
2022-06-14 22:56:39 +03:00
|
|
|
|
и предыдущая символическая ссылка заменяется символической ссылкой на новую версию.</para>
|
|
|
|
|
|
2023-11-09 20:26:01 +03:00
|
|
|
|
<para>Переменные окружения, такие как <envar>PATH</envar>, <envar>MANPATH</envar>,
|
|
|
|
|
<envar>INFOPATH</envar>, <envar>PKG_CONFIG_PATH</envar>, <envar>CPPFLAGS</envar>,
|
|
|
|
|
<envar>LDFLAGS</envar> и файл конфигурации <filename>/etc/ld.so.conf</filename>,
|
|
|
|
|
возможно, потребуется расширить, включив соответствующие подкаталоги в
|
|
|
|
|
<filename>/opt/foo-x.y</filename>.</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Этот подход используется в книге BLFS для установки некоторых очень больших пакетов,
|
|
|
|
|
чтобы упростить их обновление. Если вы устанавливаете много таких пакетов, эта схема
|
|
|
|
|
становится неуправляемой. Некоторые пакеты (например, заголовки Linux API и Glibc)
|
|
|
|
|
могут плохо работать с такой структурой. <emphasis role='bold'>Никогда не
|
|
|
|
|
используйте её в масштабах всей системы.</emphasis>
|
|
|
|
|
</para>
|
2022-06-14 22:56:39 +03:00
|
|
|
|
|
|
|
|
|
</sect3>
|
|
|
|
|
|
|
|
|
|
<sect3>
|
|
|
|
|
<title>Управление пакетами с использованием символических ссылок</title>
|
|
|
|
|
|
|
|
|
|
<para>Это разновидность предыдущей техники.Каждый пакет устанавливается аналогично,
|
2023-07-12 21:03:43 +03:00
|
|
|
|
но вместо создания символической ссылки на общее имя пакета, каждому файлу создаётся
|
|
|
|
|
символическая ссылка в иерархии каталогов <filename class='directory'>/usr</filename>.
|
2022-06-14 22:56:39 +03:00
|
|
|
|
Это исключает необходимость модификации значений переменных окружения. Хотя такие
|
2023-07-12 21:03:43 +03:00
|
|
|
|
ссылки могут быть созданы пользователем, многие менеджеры пакетов используют именной
|
|
|
|
|
такой подход. Наиболее популярные из них - Stow, Epkg, Graft и Depot.</para>
|
2022-06-14 22:56:39 +03:00
|
|
|
|
|
|
|
|
|
<para>Установку нужно сымитировать, чтобы пакет думал, что он установлен в
|
|
|
|
|
<filename class="directory">/usr</filename>, хотя на самом деле он установлен в
|
|
|
|
|
иерархии <filename class="directory">/usr/pkg</filename>. Установка таким
|
|
|
|
|
способом обычно является нетривиальной задачей. Например, предположим, что
|
|
|
|
|
вы устанавливаете пакет libfoo-1.1. Следующие инструкции могут привести к
|
|
|
|
|
неправильной установке пакета:</para>
|
|
|
|
|
|
|
|
|
|
<screen role="nodump"><userinput>./configure --prefix=/usr/pkg/libfoo/1.1
|
|
|
|
|
make
|
|
|
|
|
make install</userinput></screen>
|
|
|
|
|
|
|
|
|
|
<para>Установка будет выполнена, но зависимые пакеты не смогут ссылаться на libfoo.
|
|
|
|
|
Если вы скомпилируете пакет, который ссылается на libfoo, вы заметите, что он
|
|
|
|
|
связан с <filename class='libraryfile'>/usr/pkg/libfoo/1.1/lib/libfoo.so.1</filename>
|
|
|
|
|
вместо <filename class='libraryfile'>/usr/lib/libfoo.so.1</filename>, как вы
|
2023-07-12 21:03:43 +03:00
|
|
|
|
ожидаете. Правильный подход заключается в использовании переменной
|
|
|
|
|
<envar>DESTDIR</envar> для управления установкой. Этот подход работает следующим образом:</para>
|
2022-06-14 22:56:39 +03:00
|
|
|
|
|
|
|
|
|
<screen role="nodump"><userinput>./configure --prefix=/usr
|
|
|
|
|
make
|
|
|
|
|
make DESTDIR=/usr/pkg/libfoo/1.1 install</userinput></screen>
|
|
|
|
|
|
|
|
|
|
<para>Большинство пакетов поддерживают этот подход, но есть и такие, которые
|
|
|
|
|
этого не делают. Для несовместимых пакетов вам может потребоваться либо установить
|
2023-07-12 21:03:43 +03:00
|
|
|
|
пакет вручную, либо вы можете установить проблемные пакеты в
|
|
|
|
|
<filename class='directory'>/opt</filename>.</para>
|
2022-06-14 22:56:39 +03:00
|
|
|
|
|
|
|
|
|
</sect3>
|
|
|
|
|
|
|
|
|
|
<sect3>
|
|
|
|
|
<title>На основе временной метки</title>
|
|
|
|
|
|
|
|
|
|
<para>В этом методе файлу присваивается временная метка перед установкой пакета.
|
|
|
|
|
После установки простое использование команды <command>find</command> с
|
|
|
|
|
соответствующими параметрами может создать журнал всех файлов, установленных
|
2023-07-12 21:03:43 +03:00
|
|
|
|
после создания файла с временной метки. Менеджером пакетов, использующим этот
|
|
|
|
|
подход, является install-log.</para>
|
2022-06-14 22:56:39 +03:00
|
|
|
|
|
|
|
|
|
<para>Хотя преимущество этой схемы в том, что она проста, у нее есть два
|
|
|
|
|
недостатка. Если во время установки, файлы устанавливаются с отметкой времени,
|
|
|
|
|
отличной от текущего времени, эти файлы не будут отслеживаться менеджером пакетов.
|
2023-07-12 21:03:43 +03:00
|
|
|
|
Кроме того, эта схема может использоваться только при установке пакетов по одному.
|
|
|
|
|
Журналы ненадежны, если два пакета устанавливаются одновременно на двух разных
|
|
|
|
|
консолях.</para>
|
2022-06-14 22:56:39 +03:00
|
|
|
|
|
|
|
|
|
</sect3>
|
|
|
|
|
|
|
|
|
|
<sect3>
|
|
|
|
|
<title>Отслеживание сценариев установки</title>
|
|
|
|
|
|
|
|
|
|
<para>При таком подходе, записываются команды, выполняемые сценариями установки.
|
|
|
|
|
Есть два метода, которые можно использовать:</para>
|
|
|
|
|
|
2023-05-26 00:07:20 +03:00
|
|
|
|
<para>Переменная среды <envar>LD_PRELOAD</envar> может быть установлена так,
|
2022-06-14 22:56:39 +03:00
|
|
|
|
чтобы она указывала на библиотеку, которую нужно предварительно загрузить
|
|
|
|
|
перед установкой. Во время установки эта библиотека отслеживает устанавливаемые
|
|
|
|
|
пакеты, присоединяясь к различным исполняемым файлам, таким как <command>cp</command>,
|
|
|
|
|
<command>install</command>, <command>mv</command>, и отслеживая системные вызовы,
|
|
|
|
|
изменяющие файловую систему. Чтобы этот подход работал, все исполняемые файлы
|
|
|
|
|
должны быть динамически связаны без битов suid или sgid. Предварительная загрузка
|
|
|
|
|
библиотеки может вызвать некоторые нежелательные побочные эффекты во время
|
2023-07-12 21:03:43 +03:00
|
|
|
|
установки. Поэтому рекомендуется выполнить некоторые тесты, чтобы убедиться, что
|
|
|
|
|
менеджер пакетов ничего не сломает и что он регистрирует все соответствующие файлы.</para>
|
2022-06-14 22:56:39 +03:00
|
|
|
|
|
2023-07-12 21:03:43 +03:00
|
|
|
|
<para>Другой метод заключается в использовании <command>strace</command>, который
|
2022-06-14 22:56:39 +03:00
|
|
|
|
регистрирует все системные вызовы, сделанные во время выполнения сценариев установки.</para>
|
|
|
|
|
</sect3>
|
|
|
|
|
|
|
|
|
|
<sect3>
|
|
|
|
|
<title>Создание архивов пакетов</title>
|
|
|
|
|
|
2023-07-12 21:03:43 +03:00
|
|
|
|
<para>В этой схеме установка пакета имитируется в отдельном дереве, как описано
|
|
|
|
|
ранее в разделе управление пакетами с использованием символических ссылок.
|
|
|
|
|
После установки из установленных файлов создается архив пакета. Затем этот архив
|
|
|
|
|
используется для установки пакета на локальный компьютер или даже на другие компьютеры.</para>
|
2022-06-14 22:56:39 +03:00
|
|
|
|
|
|
|
|
|
<para>Этот подход используется большинством менеджеров пакетов, имеющихся в
|
|
|
|
|
коммерческих дистрибутивах. Примерами менеджеров пакетов, которые следуют этому
|
|
|
|
|
подходу, являются RPM (который, кстати, требуется согласно спецификации <ulink
|
2023-06-14 13:34:58 +03:00
|
|
|
|
url="https://refspecs.linuxfoundation.org/lsb.shtml">Linux
|
2022-06-14 22:56:39 +03:00
|
|
|
|
Standard Base Specification</ulink>), pkg-utils, apt Debian и система Portage
|
|
|
|
|
Gentoo. Описание того, как использовать этот стиль управления пакетами для систем
|
|
|
|
|
LFS, находится по адресу <ulink url="&hints-root;fakeroot.txt"/>.</para>
|
|
|
|
|
|
|
|
|
|
<para>Создание файлов пакетов, содержащих информацию о зависимостях, является
|
|
|
|
|
сложной задачей и выходит за рамки LFS.</para>
|
|
|
|
|
|
|
|
|
|
<para>Slackware использует систему на основе <command>tar</command> для архивов
|
|
|
|
|
пакетов. Эта система намеренно не обрабатывает зависимости пакетов, как это
|
|
|
|
|
делают более сложные менеджеры пакетов. Подробнее об управлении пакетами Slackware
|
2023-06-14 13:34:58 +03:00
|
|
|
|
см. <ulink url="https://www.slackbook.org/html/package-management.html"/>.</para>
|
2022-06-14 22:56:39 +03:00
|
|
|
|
</sect3>
|
|
|
|
|
|
|
|
|
|
<sect3>
|
|
|
|
|
<title>Пользовательское управление пакетами</title>
|
|
|
|
|
|
|
|
|
|
<para>Эта схема, уникальная для LFS, была разработана Маттиасом Бенкманом и доступна
|
|
|
|
|
в проекте <ulink url="&hints-root;">Hints</ulink>. В этой схеме каждый пакет
|
|
|
|
|
устанавливается отдельным пользователем в стандартные папки. Файлы, принадлежащие
|
|
|
|
|
пакету, легко идентифицируются путем проверки идентификатора пользователя. Особенности
|
|
|
|
|
и недостатки этого подхода слишком сложны, чтобы описывать их в этом разделе. Для
|
|
|
|
|
получения более подробной информации, пожалуйста, ознакомьтесь с советами по адресу
|
|
|
|
|
<ulink url="&hints-root;more_control_and_pkg_man.txt"/>.</para>
|
|
|
|
|
|
|
|
|
|
</sect3>
|
|
|
|
|
|
|
|
|
|
</sect2>
|
|
|
|
|
|
|
|
|
|
<sect2>
|
|
|
|
|
<title>Развертывание LFS на нескольких системах</title>
|
|
|
|
|
|
|
|
|
|
<para>Одним из преимуществ системы LFS является отсутствие файлов, зависящих от
|
|
|
|
|
положения файлов на диске. Клонировать сборку LFS на другой компьютер с той же
|
|
|
|
|
архитектурой, что и у базовой системы, так же просто, как использовать
|
|
|
|
|
<command>tar</command> для архивации раздела LFS, содержащем корневой каталог
|
2023-07-12 21:03:43 +03:00
|
|
|
|
(около 900 МБ в несжатом виде для базовой сборки LFS), скопировать этот файл
|
|
|
|
|
<!-- D. Bryant created LFS 11.2 in October 2022; 900MB is (roughly) the size of his rsync archive. -->
|
|
|
|
|
по сети или с помощью CD / USB носителя в новую систему и распаковать его. После
|
|
|
|
|
этого необходимо изменить несколько конфигурационных файлов. Файлы, которые,
|
|
|
|
|
возможно, потребуется изменить представлены в списке ниже:
|
2022-06-14 22:56:39 +03:00
|
|
|
|
<filename>/etc/hosts</filename>,
|
|
|
|
|
<filename>/etc/fstab</filename>,
|
|
|
|
|
<filename>/etc/passwd</filename>,
|
|
|
|
|
<filename>/etc/group</filename>,
|
|
|
|
|
<phrase revision="systemd">
|
|
|
|
|
<filename>/etc/shadow</filename>, и
|
|
|
|
|
<filename>/etc/ld.so.conf</filename>.
|
|
|
|
|
</phrase>
|
|
|
|
|
<phrase revision="sysv">
|
|
|
|
|
<filename>/etc/shadow</filename>,
|
|
|
|
|
<filename>/etc/ld.so.conf</filename>,
|
|
|
|
|
<filename>/etc/sysconfig/rc.site</filename>,
|
|
|
|
|
<filename>/etc/sysconfig/network</filename>, и
|
|
|
|
|
<filename>/etc/sysconfig/ifconfig.eth0</filename>.
|
|
|
|
|
</phrase>
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>Возможно, потребуется собрать собственное ядро для новой системы в зависимости
|
|
|
|
|
от различий в системном оборудовании и исходной конфигурации ядра.</para>
|
|
|
|
|
|
|
|
|
|
<note><para>Поступали некоторые сообщения о проблемах при копировании между похожими,
|
|
|
|
|
но не идентичными архитектурами. Например, набор инструкций для Intel не идентичен
|
|
|
|
|
набору инструкций для процессора AMD, и более поздние версии некоторых процессоров
|
|
|
|
|
могут содержать инструкции, недоступные в более ранних версиях.</para></note>
|
|
|
|
|
|
|
|
|
|
<para>Наконец, новую систему необходимо сделать загрузочной так, как это описано в <xref
|
|
|
|
|
linkend="ch-bootable-grub"/>.</para>
|
|
|
|
|
|
|
|
|
|
</sect2>
|
|
|
|
|
|
|
|
|
|
</sect1>
|