Наши партнеры

Книги по Linux (с отзывами читателей)

Библиотека сайта rus-linux.net

На главную -> MyLDP -> Электронные книги по ОС Linux
Linux From Scratch (version 6.8)
Назад Глава 6. Установка программ базовой системы Вперед

6.3. Управление пакетами

Часто в дополнение к книге LFS требуются средства управления пакетами. Менеджер пакетов позволит отслеживать установку файлов, что облегчает выполнение удаления и обновления пакетов. Менеджер пакетов будет управлять установкой конфигурационных файлов точно также, как двоичных файлов и файлов библиотек. И прежде, чем вы начнете задавать вопросы: НЕТ — в этом разделе не будет рассказано о каком-нибудь конкретном менеджере и не будет рекомендован какой-нибудь конкретный менеджер пакетов. Здесь будет дано общее описание наиболее популярных методов управления пакетами и то, как эти методы работают. Одним из этих методов может пользоваться менеджер пакетов, который будет лучшим для вас, либо это может быть комбинация двух или большего числа методов. В данном разделе кратко упоминаются вопросы, которые могут возникнуть при обновлении пакетов.

Есть несколько причины, почему в книгах LFS или BLFS не упоминаются менеджеры пакетов:

  • Вопросы, связанные с управлением пакетами, будут отвлекать внимание от основной цели этих книг - обучения сборке системы Linux.
  • Для управления пакетами предлагается множество решений, каждое из которых имеет свои сильные стороны и недостатки. Трудно выбрать такое, которое бы удовлетворило всех.

Есть несколько рекомендаций, касающихся управления пакетами. Посетите страницу рекомендаций Hints Project и поищите те рекомендации, которые подойдут вам.

6.3.1. Вопросы, связанные с обновлениями

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

  • Если один из пакетов набора инструментальных средств (Glibc, GCC и Binutils) нуждается в незначительном обновлении, будет безопаснее пересобрать систему LFS. Хотя вы можете сделать это путем пересборки всех пакетов в том порядке, в котором они зависят друг от друга, мы не рекомендуем делать это. Например, если библиотеку glibc-2.2.x необходимо обновить до версии glibc-2.3.x, то безопаснее ее пересобрать. В случае микрообновлений простая переустановка обычно работает, но не всегда гарантированно. Например, обновление с glibc-2.3.4 до glibc-2.3.5, как правило, не вызывает никаких проблем.
  • Если обновляется пакет, в котором находится совместно используемая библиотека, и если имя библиотеки изменяется, то все пакеты, которые динамически связаны с этой с библиотекой, нужно заново скомпилировать для того, чтобы скомпоновать с новой библиотекой. (Заметьте, что между версией пакета и именем библиотеки нет никакой взаимосвязи). Рассмотрим, например, пакет foo-1.2.3, с помощью которого устанавливается совместно используемая библиотека с именем libfoo.so.1. Скажем, вы обновляете пакет до новой версии foo-1.2.4, с помощью которого устанавливается совместно используемая библиотека с именем libfoo.so.2. В этом случае, все пакеты, которые динамически связаны с библиотекой libfoo.so.1, следует перекомпилировать с библиотекой libfoo.so.2. Обратите внимание, что вы не должны удалять предыдущие библиотеки до тех пор, пока не будут перекомпилированы все зависимые пакеты.

6.3.2. Методы управления пакетами

Ниже приведены некоторые общие методы управления пакетами. Прежде, чем принимать решение о выборе менеджера пакетов, проведите некоторые исследования различных методов, в частности, разберитесь с недостатками каждой конкретной схемы.

6.3.2.1. Все у меня в памяти!

Да, это метод управления пакетами. Некоторым спецам менеджер пакетов не нужен, поскольку они хорошо знакомы с пакетами и знают, какие файлы устанавливает каждый пакет. Некоторым пользователям также не нужно никаких менеджеров пакетов, поскольку они планируют пересобрать всю систему, когда пакет изменяется.

6.3.2.2. Установка в отдельные директории

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

В переменных среды окружения, такие как PATH, LD_LIBRARY_PATH, MANPATH, INFOPATH и CPPFLAGS должен быть указан директорий /usr/pkg/foo. Если пакетов много, то эта схема становится неуправляемой.

6.3.2.3. Управление пакетами с использованием символических ссылок

Это вариация предыдущего метода управления пакетами. Каждый пакет устанавливается аналогично предыдущей схеме. Но вместо того, чтобы делать символическую ссылку в иерархии /usr делаются символические ссылки на каждый файл. Это устраняет необходимость добавлять директорий в переменные среды окружения. Хотя символические ссылки могут создаваться пользователем, который может автоматизировать их создание, многие менеджеры пакетов были написаны с использованием этого подхода. К ним относятся несколько популярных менеджеров, к которым относятся Stow, Epkg, Graft и Depot.

Установка должна быть фиктивной, поскольку пакет считает, что он установлен в директорий /usr, хотя в действительности он будет установлен в иерархию /usr/pkg. Такая установка обычно является нетривиальной задачей. Предположим, например, что вы устанавливаете пакет libfoo-1.1. С помощью следующих инструкций пакет не удастся установить правильно:

./configure --prefix=/usr/pkg/libfoo/1.1
make
make install

Установка будет выполнена, но зависимые пакеты не смогут ссылаться на libfoo так, как вы ожидаете. Если вы компилируете пакет, который ссылается на libfoo, вы можете заметить, что ссылка делается на /usr/pkg/libfoo/1.1/lib/libfoo.so.1, а не на /usr/lib/libfoo.so.1, как следовало ожидать. Правильный подход заключается в использовании в фиктивной установке пакета стратегии DESTDIR. Этот подход работает следующим образом:

./configure --prefix=/usr
make
make DESTDIR=/usr/pkg/libfoo/1.1 install

Этот подход поддерживается в большинстве пакетов, есть некоторые пакеты, в которых поддержки нет. Для таких пакетов вам, возможно, потребуется вручную установить пакет, либо вы можете решить, что некоторые проблемные пакеты легче установить в директорий /opt.

6.3.2.4. Использование временных меток

В этом методе файлу перед установкой пакета присваивается временная метка. После установки, простое использование команды find с соответствующими параметрами поможет сгенерировать журнал всех файлов, установленных после того, как файлу была присвоена временная метка. Менеджер пакетов, использующий этот метод, называется методом журнала установок.

Хотя эта схема имеет то преимущество, что она проста, в ней есть два недостатка. Если в процессе установки будут установлены файлы с временной меткой, отличающейся от текущего значения времени, то эти файлы не удастся отследить с помощью менеджера пакетов. Кроме того, эту схему можно использовать только тогда, когда в каждый момент устанавливается только один пакет. Журналы не помогут, если на двух различных консолях будут устанавливаться два пакета.

6.3.2.5. Трассировка инсталляционных скриптов

При таком подходе записываются команды, которые выполняют инсталляционные скрипты. Есть два метода, один из которых можно использовать:

Можно установить переменную среды окружения LD_PRELOAD, указывающую на библиотеку, которая должна быть перед установкой предварительно загружена. Во время установки эта библиотека отслеживает устанавливаемые пакеты; отслеживание осуществляется путем подключения библиотеки к таким исполняемым командам, как cp, install, mv и отслеживание системных вызовов, которые модифицируют файловую систему. Чтобы этот подход сработал, все исполняемые команды быть динамически скомпонованы без использования бита suid или sgid. Предварительная загрузка библиотеки может во время установки вызвать некоторые нежелательные побочные эффекты. Поэтому желательно выполнить ряд тестов с тем, чтобы убедиться, что менеджер пакетов ничего не нарушает и регистрирует все требуемые файлы.

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

6.3.2.6. Создание архивов пакетов

В этой схеме установка пакета осуществляется фиктивно в отдельное дерево так, как описано в разделе управления пакета с использованием символических ссылок. После установки из установленных файлов создается архив пакета. Затем этот архив используется для установки пакетов либо на локальной машине, либо даже может быть использован для установки пакета на других машинах.

Этот подход используется в большинстве менеджеров пакетов, которые можно найти в коммерческих дистрибутивах. Примерами менеджеров пакетов, в которых используется этот подход, являются RPM (который, кстати, требуется согласно спецификации Linux Standard Base Specification), PKG-утилиты, pkg-utils, apt в Debian и система портежей в Gentoo. Описание того, как приспособить этот стиль управления пакетами к системе LFS, расположено на http://www.linuxfromscratch.org/hints/downloads/files/fakeroot.txt.

Создание файлов, в которых находится информация о зависимостях в пакетах, является сложной задачей и выходит за рамки проекта LFS.

В Slackware для создания архивов пакетов используется система tar. В этой системе сознательно не обрабатываются зависимости пакетов, как это делается в более сложных менеджерах пакетов. Более подробную информацию об управлении пакетами в системе Slackware смотрите на http://www.slackbook.org/html/package-management.html.

6.3.2.7. Управление с созданием пользователей

Эта схема, уникальная для системы LFS, была разработана Маттиассом Бенкманном (Matthias Benkmann) и доступна в рекомендациях Hints Project. Согласно этой схеме каждый пакет должен устанавливаться отдельным пользователем в стандартных для этого местах. Файлы, принадлежащие пакету, легко идентифицируются при помощи проверки идентификатора пользователя. Преимущества и недостатки этого подхода достаточно сложны с тем, чтобы их можно было описать в этом разделе. Более подробную информацию об этом смотрите на http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt.

6.3.3. Развертывание системы LFS на других машинах

Одно из преимуществ системы LFS состоит в том, отсутствуют файлы, зависящие от своего месторасположения на диске. Клонирование сборки системы LFS на другой компьютер с архитектурой, похожей на базовую систему, является столь же простым, как архивирование раздела LFS с помощью команды tar, в котором находится директорий root (размер около 250 МБ в несжатом виде для базовой сборки системы LFS), копирования заархивированного файла по сети или передача его с помощью CD-ROM на новую систему и распаковывания его там. Затем нужно будет изменить несколько конфигурационных файлов. К числу конфигурационных файлов, которые может потребоваться изменить, относятся следующие: /etc/hosts, /etc/fstab, /etc/passwd, /etc/group, /etc/shadow, /etc/ld.so.conf, /etc/scsi_id.config, /etc/sysconfig/network и /etc/sysconfig/network-devices/ifconfig.eth0/ipv4.

Если есть различия в аппаратных средствах или исходной конфигурации ядра, то может потребоваться собрать для новой системы специально настроенное ядро.

Наконец, новую систему следует сделать загружаемой так, как это описано в разделе 8.4 "Использование загрузчика GRUB для настройки процесса загрузки".

Предыдущий раздел: Оглавление Следующий раздел:
Подготовка виртуальных файловых систем ядра   Переход в среду chroot