Управление пакетами является часто запрашиваемым дополнением к книге LFS. Менеджер пакетов позволяет отслеживать установку файлов, делая легким их удаление, и обновлять пакеты. И перед тем, как вы начнете радоваться, НЕТ—этот раздел ни рассказывает о каком-нибудь особенном менеджере пакетов, ни рекомендует. Здесь предоставляется обзор наиболее популярных способов и как они работают. Наилучший для вас менеджер пакетов может быть среди этих способов или может быть комбинацией из нескольких. Этот раздел коротко оговаривает проблемы, которые могут появиться при обновлении пакетов.
Некоторые основания, почему менеджеры пакетов не описаны в LFS или BLFS:
Рассмотрение управления пакетами сфокусировано вокруг целей этой книги—обучению того, как строить Линукс систему.
Существует много решений по управлению пакетами, имеющие собственные преимущества и недостатки.
Существует несколько советов, написанных на тему управления пакетами. Посетите Подпроект советов для поиска подходящего для вас варианта.
Менеджер пакетов делает обновление пакетов на более новую версию при ее появлении. Обычно инструкции, описанные в книгах LFS и BLFS, могут быть использованы для обновления на новые версии. Есть несколько моментов, которые вы должны знать при обновлении пакетов, особенно на работающей системе.
Если один из основных пакетов (glibc, gcc, binutils) надо обновить на новую младшую версию, то безопаснее персобрать LFS. Вы можете сделать это пересборкой всех пакетов в порядке их зависимостей. Мы это не рекомендуем. Например, если glibc-2.2.x необходимо обновить до glibc-2.3.x, то безопаснее пересобрать. Для незначительного обновления версий обычно работает простая переустановка, но не гарантировано. Например, обновление от glibc-2.3.1 до glibc-2.3.2 обычно не будет означать каких-либо проблем.
Если обновлен пакет, содержащий разделяемые библиотеки, и если имена библиотек изменились, то все пакеты, динамически скомпонованные с этими библиотеками, должны быть перекомпилированы для связи с новыми библиотеками. Заметьтьте, что это не кореляция между версией пакета и именем библиотеки. Например, рассмотрим пакет foo-1.2.3, который устанавливает разделяемую библиотеку с именем libfoo.so.1. Скажем, вы обновляете пакет на новую версию foo-1.2.4, которая устанавливает разделяемую библиотеку с именем libfoo.so.2. В этом случае все пакеты, которые динамически скомпонованы с libfoo.so.1, необходимо перекомпилировать для компоновки с libfoo.so.2. Заметьте, что вы не должны удалять предидущие библиотеки, пока зависимые пакеты перекомпилируются.
Если вы обновляете запущенную систему, будьте внимательны с пакетами, которые используют cp вместо install для установки файлов. Последняя команда обычно безопаснее, если программа или библиотека уже загружена в память.
Следующее является общим в способах управления пакетами. Перед принятием решения о менеджере пакетов проведите поиск различных способов, особенно недостатков отдельных схем.
Да, это техника управления пакетами. Некоторые люди не видят необходимости в управлении пакетами потому, что они знают пакеты лично и знают, какие файлы установлены каждым пакетом. Некоторые пользователи так же не нуждаются в любом управлении пакетами потому, что они планируют пересборку целой системы при изменении пакета.
Это простейшее управление пакетами, которое не требует дополнительных пакетов для управления установкой. Каждый пакет устанавливается в отдельную директорию. Например, пакет foo-1.1 установлен в /usr/pkg/foo-1.1 и сделана ссылка из /usr/pkg/foo на /usr/pkg/foo-1.1. Когда устанавливается новая версия foo-1.2, она устанавливается в /usr/pkg/foo-1.2 и предидущая ссылка заменяется ссылкой на новую версию.
Переменные окружения, описанные в разделе “После BLFS”, необходимо расширить для включения /usr/pkg/foo. Для более чем нескольких пакетов такая схема становиться неуправляемой.
Это вариация предидущей техники управления пакетами. Каждый пакет установлен аналогично предидущей схеме. Но установлен, делая ссылку на каждый файл в иерархию /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.
При такой технике файл перед установкой пакета отмечается по времени. После установки пакета простое использование команды find с соответствующими опциями может сгенерировать лог обо всех файлах, установленных после создания файла, отмеченного по времени. Менеджер пакетов, написанный с таким подходом - это install-log.
Хотя такая схема имеет преимущество простоты, она имеет два недостатка. Если во время установки файлы установлены с другой отметкой по времени, не соответствующей текущему времени, то они не будут отслежены менеджером пакетов. Так же эта схема может быть использована только тогда, когда за одно время установлен один пакет. Логи не надежны, если два пакета были установлены на двух различных консолях.
При таком подходе библиотека перед установкой предзагружается. В течении установки эта библиотека отслеживает пакеты, которые были установлены, присоединением себя к различным исполняемым файлам, таким, как cp, install, mv и отслеживают системные вызовы, изменяющие файловую систему. Для работы такого метода, все исполняемые файлы должны быть скомпонованы динамически без битов suid или sgid. Предзагрузка библиотеки может означать некоторые нежелательные эффекты во время установки. Хотя, выполните некоторые тесты, чтобы убедиться, что менеджер пакетов ничего не портит и отчитывается о всех соответствующих файлах.
При такой схеме установка пакета перенаправляется в отдельное дерево, как описано в методе управления пакетами, основанном на ссылках. После установки создается архив пакета, использующий установленные файлы. Этот архив затем используется для установки пакета как на текущую машину, так и может быть установлен на другую.
Такой метод используется в большинстве менеджеров пакетов, находящихся в комерческих дистрибутивах. Примеры менеджеров пакетов, соответствующих этому методу, это RPM, pkg-utils, apt Debian-а и система портежей Gentoo.
Эта схема, которая уникальна для LFS, была придумана Matthias Benkmann, и доступна на Hints Project. В этой схеме каждый пакет установлен под отдельным пользователем в стандартные места. Файлы, принадлежащие пакету, идендифицируются просто проверкой ID пользователя. Преимущества и недостатки этого способа слишком комплексны для описания в этом разделе. Для большей информации обратитесь к совету на http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt.