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

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

+ Некоторые причины, по которым менеджер пакетов не упоминается в LFS + или BLFS представлены ниже: +

+
+ Рассмотрение управления пакетами отвлекает внимание от целей + этих книг—обучения тому, как строится система Linux. +
+
+
+ Существует множество решений для управления пакетами, каждое из + которых имеет свои сильные и слабые стороны. Трудно найти + такое, которое удовлетворит всех. +
+

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

+ 8.2.1. Проблемы с обновлением +

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

+
+ Если нужно обновить ядро Linux (например, с 5.10.17 до + 5.10.18 или 5.11.1), дополнительно пересобирать ничего не + нужно. Система продолжит нормально работать благодаря четко + определенной границе между ядром и пользовательским + пространством. В частности, заголовки Linux API не нужно + обновлять вместе с ядром. Вам просто нужно перезагрузить + систему, чтобы использовать обновленное ядро. +
+
+
+ Если необходимо обновить Glibc до более новой версии + (например, с Glibc-2.36 до Glibc-2.40) необходимо выполнить + некоторые дополнительные действия, чтобы избежать поломки + системы. Подробности читайте в Раздел 8.5, + «Glibc-2.40». +
+
+
+ Если пакет, содержащий общую библиотеку, обновляется и имя + библиотеки изменилось, то любые пакеты, динамически связанные + с библиотекой, необходимо перекомпилировать, чтобы связать с + более новой библиотекой. (Обратите внимание, что между + версией пакета и именем библиотеки нет никакой связи.) + Например, рассмотрим пакет foo-1.2.3, который устанавливает + общую библиотеку с именем libfoo.so.1. Предположим, вы обновили пакет + до более новой версии foo-1.2.4, которая устанавливает общую + библиотеку с именем libfoo.so.2, все пакеты, которые + динамически связаны с libfoo.so.1, должны быть перекомпилированы + для связи с libfoo.so.2, чтобы + использовать новую версию библиотеки. Вы не должны удалять + старые библиотеки, пока все зависимые пакеты не будут + перекомпилированы. +
+
+
+ Если пакет (прямо или косвенно) связан как со старым, так и с + новым именем общей библиотеки (например, пакет ссылается как + на libfoo.so.2, так и на + libbar.so.1, в то время как + последний ссылается на libfoo.so.3), пакет может работать + неправильно, поскольку разные версии общей библиотеки + содержат несовместимые определения для некоторых имен + символов. Это может быть вызвано перекомпиляцией некоторых, + но не всех, пакетов, связанных со старой общей библиотекой, + после обновления пакета, предоставляющего общую библиотеку. + Чтобы избежать этой проблемы, пользователям необходимо как + можно скорее пересобрать каждый пакет, связанный с общей + библиотекой, с обновленной версией (например, с libfoo.so.2 + на libfoo.so.3). +
+
+
+ Если пакет, содержащий общую библиотеку, обновляется, а имя + библиотеки не меняется, но уменьшается номер версии + файла библиотеки + (например, библиотека по-прежнему называется libfoo.so.1, но имя файла библиотеки + изменилось с libfoo.so.1.25 на + libfoo.so.1.24), следует + удалить файл библиотеки ранее установленной версии (в данном + случае libfoo.so.1.25). В + противном случае, команда ldconfig (запущенная + самостоятельно с помощью командной строки или при установке + какого-либо пакета) приведёт к сбросу символической ссылки + libfoo.so.1, которая будет + указывать на старый файл библиотеки, потому что кажется, что + она имеет «более + новую» версию, поскольку её номер версии + больше. Такая ситуация может произойти, если вам нужно + понизить версию пакета или авторы изменили схему управления + версиями файлов библиотеки. +
+
+
+ Если пакет, содержащий общую библиотеку, обновляется, а имя + библиотеки не меняется, но устраняется серьезная проблема + (особенно уязвимость в системе безопасности), необходимо + перезапустить все работающие программы, связанные с общей + библиотекой. Следующая команда, запущенная от имени + пользователя root после + завершения обновления, выведет список программ, которые + использует старые версии этих библиотек (замените libfoo именем библиотеки): +
+
```
grep -l 'libfoo.*deleted' /proc/*/maps | tr -cd 0-9\\n | xargs -r ps u
```
+
+ Если для доступа к системе используется OpenSSH и он связан с обновленной + библиотекой, вам необходимо перезапустить службу sshd, затем выйти из + системы, снова войти в систему и повторно выполнить + предыдущую команду, чтобы убедиться, что удаленные библиотеки + более не используются. +
+
+
+ Если исполняемая программа или библиотека перезаписаны, + процессы, использующие код или данные из них, могут + завершиться сбоем. Правильный способ обновить программу или + общую библиотеку, не вызывая сбоя процесса, - это сначала + удалить его, а затем установить новую версию. Команда + install, + предоставляемая Coreutils, + уже реализовала это, и большинство пакетов используют ее для + установки двоичных файлов и библиотек. Это означает, что + большую часть времени вас не будет беспокоить эта проблема. + Однако процесс установки некоторых пакетов (в частности, + SpiderMonkey в BLFS) просто перезаписывает файл, если он + существует, и вызывает сбой. Поэтому безопаснее сохранить + свою работу и закрыть ненужные запущенные программы перед + обновлением пакета. +
+

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

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

+ 8.2.2.1. Всё у меня в голове! +

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

+ 8.2.2.2. Установка в отдельные каталоги +

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

+ Переменные окружения, такие как PATH, + MANPATH, INFOPATH, PKG_CONFIG_PATH, CPPFLAGS, LDFLAGS и + файл конфигурации /etc/ld.so.conf, + возможно, потребуется расширить, включив соответствующие + подкаталоги в /opt/foo-x.y. +

+ Этот подход используется в книге BLFS для установки некоторых + очень больших пакетов, чтобы упростить их обновление. Если вы + устанавливаете много таких пакетов, эта схема становится + неуправляемой. Некоторые пакеты (например, заголовки Linux API и + Glibc) могут плохо работать с такой структурой. Никогда не используйте её в масштабах всей + системы. +

+ 8.2.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. +

+ 8.2.2.4. На основе временной метки +

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

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

+ 8.2.2.5. Отслеживание сценариев установки +

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

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

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

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

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

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

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

+ Slackware использует систему на основе tar для архивов пакетов. Эта + система намеренно не обрабатывает зависимости пакетов, как это + делают более сложные менеджеры пакетов. Подробнее об управлении + пакетами Slackware см. https://www.slackbook.org/html/package-management.html. +

+ 8.2.2.7. Пользовательское управление пакетами +

+ Эта схема, уникальная для LFS, была разработана Маттиасом + Бенкманом и доступна в проекте Hints. + В этой схеме каждый пакет устанавливается отдельным пользователем + в стандартные папки. Файлы, принадлежащие пакету, легко + идентифицируются путем проверки идентификатора пользователя. + Особенности и недостатки этого подхода слишком сложны, чтобы + описывать их в этом разделе. Для получения более подробной + информации, пожалуйста, ознакомьтесь с советами по адресу + + https://mirror.linuxfromscratch.ru/hints/downloads/files/more_control_and_pkg_man.txt. +

+ 8.2.3. Развертывание LFS на нескольких системах +

+ Одним из преимуществ системы LFS является отсутствие файлов, + зависящих от положения файлов на диске. Клонировать сборку LFS на + другой компьютер с той же архитектурой, что и у базовой системы, + так же просто, как использовать tar для архивации раздела LFS, + содержащем корневой каталог (около 900 МБ в несжатом виде для + базовой сборки LFS), скопировать этот файл по сети или с помощью CD + / USB носителя в новую систему и распаковать его. После этого + необходимо изменить несколько конфигурационных файлов. Файлы, + которые, возможно, потребуется изменить представлены в списке ниже: + /etc/hosts, /etc/fstab, /etc/passwd, /etc/group, /etc/shadow, /etc/ld.so.conf, /etc/sysconfig/rc.site, /etc/sysconfig/network, и /etc/sysconfig/ifconfig.eth0. +

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

+ Примечание +

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

+ Наконец, новую систему необходимо сделать загрузочной так, как это + описано в Раздел 10.4, + «Использование GRUB для настройки процесса загрузки». +

+ Линукс с нуля - Версия 12.2 +

+ Глава 8. Установка базового системного программного обеспечения +

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