LFS_Book/chapter06/pkgmgt.xml

<?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>

  <para>Часто задаваемый вопрос по книге LFS - управление пакетами. Менеджер пакетов позволяет отслеживать установку файлов, делая процесс удаления и обновления пакетов существенно проще. Кроме файлов и библиотек, пакетный менеджер будет управлять установкой файлов конфигурации. Не удивляйтесь, в этом разделе не будет информации и рекомендаций по поводу пакетного менеджера. В этом разделе, будет представлена информация о наиболее популярных механизмах работы пакетного менеджера. Идеальным пакетным менеджером для вас может стать такая программа, которая способна комбинировать несколько техник. В этом разделе также кратко упоминается о тех проблемах, которые могут возникнуть при обновлении пакетов:</para>

  <itemizedlist>
    <listitem>
      <para>Работа с системами управления пакетов отвлекает внимание от целей этой книги - обучение тому, как построена Linux система.</para>
    </listitem>

    <listitem>
      <para>Существует множество решения, для управления пакетами. Каждый из них имеет свои достоинства и недостатки. Угодить всем - трудно.</para>
    </listitem>
  </itemizedlist>

  <para>Есть несколько советов, которые содержатся в проекте <ulink url="&hints-index;">Советы</ulink>.  Ознакомьтесь с ними, возможно вы найдете решение, которое соответствует вашим потребностям.</para>

  <sect2>
    <title>Проблемы с обновлением</title>

    <para>пакетный менеджер действительно упрощает обновление пакетов до новых версий, когда они публикуются. Как правило, инструкции в книгах LFS и BLFS могут быть использованы для обновления до новых версий. Вот некоторые моменты, которые необходимо учесть при обновлении пакетов до новых версий, особенно если обновление происходит на запущенной системе.</para>

    <itemizedlist>
      <listitem>
        <para>Если необходимо обновить пакет Glibc до новой версии (например с 2.19 до 2.20) безопаснее всего выполнить сборку всей системы LFS заново. Также, можно выполнить пересборку всех пакетов в порядке их зависимостей. Но такой подход не рекомендуется.</para>
      </listitem>

      <listitem>
        <para>Если пакет содержащий разделяемую (shared) библиотеку обновлён, и наименование библиотеки изменилось, тогда все пакеты, которые динамически скомпонованы к библиотеке нужно заново компилировать, с указанием на новую версию библиотеки.(Обратите внимание, что нет никакой корреляции между версией пакета и имени библиотеки.). Например, рассмотрим пакет foo-1.2.3 который установил разделяемую библиотеку с наименованием <filename class='libraryfile'>libfoo.so.1</filename>. Допустим, вы обновили пакет до новой версии - foo-1.2.4, который установил новую версию разделяемой библиотеки <filename class='libraryfile'>libfoo.so.2</filename>. В данном случае,  все пакеты, динамически слинкованные на библиотеку  <filename class='libraryfile'>libfoo.so.1</filename> должны  быть заново скомпилированы с указанием на новую версию библиотеки <filename class='libraryfile'>libfoo.so.2</filename>. Обратите внимание, что не следует удалять предыдущие версии библиотек до тех пор, пока все пакеты, которые на нёё ссылаются не перекомпилированы.</para>
      </listitem>
    </itemizedlist>

  </sect2>

  <sect2>
    <title>Методы управления пакетами</title>

    <para>Ниже приведены некоторые общие методы управления пакетами. До принятия решения о менеджере пакетов, проведите  некоторое исследование различных методов, особенно обратите внимание на их недостатки.</para>

    <sect3>
      <title>Все у меня в голове!</title>

      <para>Да, это метод управления пакетами. Некоторым пользователям не нужен пакетный менеджер, потому что они прекрасно знают все установленные пакеты, и какие файлы им принадлежат. Некоторым пользователям также не требуется пакетный менеджер, потому что они пересобирают всю систему когда пакет поменяется.</para>

    </sect3>

    <sect3>
      <title>Установка в отдельные каталоги</title>

      <para>Это упрощенная техника, для которой не требуются дополнительные программы или пакеты, для управления установкой. Каждый пакет устанавливается в отдельный каталог. Например пакет foo-1.1 будет установлен в каталог <filename class='directory'>/usr/pkg/foo-1.1</filename> и символическая ссылка будет создана с <filename class='directory'>/usr/pkg/foo</filename> на каталог <filename class='directory'>/usr/pkg/foo-1.1</filename>. При установке новой версии пакета foo-1.2, он будет установлен в каталог <filename class='directory'>/usr/pkg/foo-1.2</filename> а предыдущая символическая ссылка будет заменена символической ссылкой на каталог с новой версией пакета.</para>

      <para>Переменные окружения, такие как <envar>PATH</envar>,<envar>LD_LIBRARY_PATH</envar>,<envar>MANPATH</envar>,<envar>INFOPATH</envar> и <envar>CPPFLAGS</envar> необходимо расширить, включив каталог <filename>/usr/pkg/foo</filename>. Для большого количества пакетов, такая техника становится неуправляемой.</para>

    </sect3>

    <sect3>
      <title>Управление пакетами с использованием символических ссылок</title>

      <para>Это вариация предыдущей техники.Каждый пакет устанавливается аналогично, но вместо создания символической ссылки, каждому файлу создаётся символическая ссылка в иерархию каталогов <filename class='directory'>/usr</filename>. Это исключает необходимость модификации значений переменных окружения. Такие ссылки могут быть созданы пользователям вручную, для автоматизации создания пакетов, однако, многие менеджеры пакетов были созданы с использованием именной такого метода. Наиболее популярные из них - Stow,
      Epkg, Graft, and Depot.</para>

      <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> как и следовало ожидать. Правильный подход заключается в использовании переменной окружения  <envar>DESTDIR</envar> чтобы подделать установку пакета. Такой метод работает следующим образом:</para>

<screen role="nodump"><userinput>./configure --prefix=/usr
make
make DESTDIR=/usr/pkg/libfoo/1.1 install</userinput></screen>

      <para>Большинство пакетов поддерживают такой способ, но некоторые нет. Для несовместимых пакетов, вам понадобится вручную выполнить установку пакета, или еще проще устанавливать такие пакеты в каталог <filename class='directory'>/opt</filename>.</para>

    </sect3>

    <sect3>
      <title>На основе временной метки</title>

      <para>Файлу присваивается метка времени, перед установкой пакета. После установки, выполняется команда <command>find</command> с соответствующими параметрами, результат выполнения которой будет представлять из себя журнал со всеми файлами установленных после указанной метки времени. Пакетный менеджер, использующий такой подход имеет журнал установки.</para>

      <para>Этот метод имеет преимущество - простота, но имеет и несколько недостатков. В процессе установки, файлы, которые были установленны с другими метками времени, которые отличаются от текущего времени, не будут отслеживаться пакетным менеджером. Также, возможно устанавливать один пакет за раз. Журналы ненадежны, если два пакета установлены их двух разных терминалов.</para>

    </sect3>

    <sect3>
      <title>Отслеживание сценариев установки</title>

      <para>Этот метод заключается в записи команд, выполняемых сценарием установки. Есть два подхода, как использовать данный метод:</para>

      <para>Переменная окружения <envar>LD_PRELOAD</envar> может быть указана на предварительно загруженную библиотеку перед установкой. В процессе установки эта библиотека отслеживает пакеты, которые будут установлены присоединяя себя к различным исполняемым файлам, таким как <command>cp</command>,<command>install</command>, <command>mv</command> для отслеживания системных вызовов, которые вносят изменения в файловую систему. Для работоспособности этого метода, все исполняемые файлы должны быть динамически связаны без использования битов suid или sgid. Предзагрузка библиотеки может вызвать нежелательные побочные эффекты в процессе установки. Поэтому, рекомендуется выполнить тесты, для того, чтобы гарантировать, что пакетный менеджер не испортил что-либо и отследил все необходимые файлы.</para>

      <para>Второй подход заключается в использовании программы <command>strace</command>, которая регистрирует все системные вызовы, во время выполнения сценариев установки.</para>
    </sect3>

    <sect3>
      <title>Создание архивов для пакетов</title>

      <para>При этой схеме, установка будет подменена в отдельное дерево каталогов, как описано в разделе  Управление пакетами с использованием символических ссылок. После установки, архив с пакетом создается используя установленные файлы. Этот архив теперь будет использоваться для установки пакета либо на локальном компьютере, либо может использоваться на других машинах.</para>

      <para>Этот подход используется большинством пакетных менеджеров в коммерческих дистрибутивах. Примеры пакетных менеджеров которые следуют этому подходу - RPM (который, кстати, требуется в базовой спецификации <ulink
      url="http://refspecs.linuxfoundation.org/lsb.shtml">Linux Standard Base Specification (LSB) </ulink>),pkg-utils, apt дистрибутива Debian и система портов Gentoo. Подсказка, описывающая, как принять этот стиль управления пакетами для систем LFS, находится по адресу <ulink
      url="&hints-root;fakeroot.txt"/>.</para>

      <para>Создание файлов пакетов, содержащих информацию о зависимостях, является сложным и выходит за рамки LFS.</para>

      <para>Дистрибутив Slackware использует основанную на <command>tar</command> систему для архивации пакетов. Эта система намеренно не обрабатывает зависимости пакетов как это делают более сложные менеджеры пакетов. Подробнее об управлении пакетов в Slackware см.<ulink
      url="http://www.slackbook.org/html/package-management.html"/>.</para>
    </sect3>

    <sect3>
      <title>Пользовательское управление пакетами.</title>

      <para>Эта схема является уникальной для LFS была разработана Матиасом Бенкманом, и описание доступно по ссылке
		<ulink url="&hints-index;">Hints Project</ulink>. Суть схемы в том, что каждый пакет, будет установлен как отдельный пользователь в стандартном местоположении. Файлы, принадлежащие пакету легко идентифицируются, путём определения пользовательского идентификатора. Особенности и недостатки этого подхода слишком сложны для описания в этом разделе. Подробнее см. <ulink url="&hints-root;more_control_and_pkg_man.txt"/>.</para>

    </sect3>

  </sect2>

  <sect2>
    <title>Развертывание LFS и распространение</title>

    <para>Одно из преимуществ системы LFS является то, что нет файлов, у которых есть строгая привязка к местоположению на диске. Можно запаковать корневой раздел (около 250MB в несжатом виде для базовой сборки LFS), например программой <command>tar</command>, скопировать по сети или записать на компакт-диск. А затем выполнить распаковку в требуемое место, и выполнить конфигурацию некоторых файлов, для правильного функционирования системы. Файлы, которые потерубется изменить включают в себя:

    <filename>/etc/hosts</filename>,
    <filename>/etc/fstab</filename>,
    <filename>/etc/passwd</filename>,
    <filename>/etc/group</filename>,
    <phrase revision="systemd">
      <filename>/etc/shadow</filename>, and
      <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>, and
      <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>