Периодическая таблица дистрибутивов Linux

4. Средства управления пакетами ПО

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

Программное обеспечение, содержащееся в пакете, поставляется в одном из двух основных видов:

• в виде бинарных файлов, которые предназначены для непосредственой установки в вашу систему, без какой-либо дополнительной обработки (например, компиляции).
• в виде исходных текстов, которые обычно содержат текст на каком-то языке программирования, заархивированный в формате tar и упакованный программой gzip, а также вспомогательные файлы, необходимые для компиляции приложения из файлов пакета.

Существуют также пакеты, которые можно при желании отнести как к первому, так и ко второму виду. Это пакеты, которые содержат скрипты и конфигурационные файлы, страницы руководств в формате man/info, информацию о копирайтах и другую документацию. С одной стороны, они представляют собой такие же "исходные тексты", с другой - устанавливаются в систему без всякой дополнительной обработки, как и исполняемые файлы. Но этот тип пакетов играет вспомогательную роль и для нас какого-либо интереса не представляет. А вот количество и состав пакетов первых двух типов играет в классификации дистрибутивов самую существенную роль.

Вспомним, во-первых, что все программное обеспечение в Linux является открытым, то есть поставляется вместе с исходными кодами. И поэтому для каждого бинарного пакета на дистрибутивных дисках найдется соответствующий ему пакет с исходными кодами. А вот обратное утверждение уже не имеет места, так как существуют дистрибутивы, в которых число бинарных пакетов сильно ограничено. Это так называемые "Source-based" дистрибутивы, то есть дистрибутивы, основанные на исходных кодах. Их создатели предполагают, что пользователь такого дистрибутива может самостоятельно скомпилировать и установить в систему любое нужное ему приложение. Но ведь для того, чтобы запустить процесс компиляции, система в какой-то минимальной конфигурации уже должна работать. Должны быть установлены загрузчик, ядро, архиваторы tar и gzip (чтобы развернуть пакет с исходниками), компилятор со всем сопутствующим инструментарием (линкером, ассемблером и т.д.), библиотеки функций языка Си, утилиты для работы с файлами и текстами (find, grep, awk, sed), без которых сборка и установка программ просто невозможна. Эта проблема решается двумя способами: либо компиляция проходит на какой-то другой системе, либо необходимый минимум прекомпилированных пакетов устанавливается из дистрибутива, а остальные компилируются уже в полученной таким образом среде. Самый яркий пример реализации подхода, основанного на компиляции всей системы из исходных кодов - проект Linux From Scratch, который не является дистрибутивом в прямом смысле этого слова, а представляет собой набор инструкций по созданию системы из набора пакетов с исходными кодами (см. [10]).

Что же касается пакетов с прекомпилированным программным обеспечением, то для установки как в поцессе инсталляции, так и в уже установленой системе требуются специальные средства управления пакетами. Дело в том, что установка программного обеспечения из пакетов обычно связана с разрешением так называемых "зависимостей". Например, пакет, содержащий компилятор GNU C (gcc) "зависит" от пакета binutils, который включает в себя компоновщик и транслятор. Если пользователь попытается установить gcc без предварительной установки binutils, процесс установки пакета с GCC скорее всего завершится сообщением об ошибке. Поэтому в состав пакета обычно включается не только бинарный код исполняемой программы, но еще и некая служебная или мета-информация: название программы, данные о разработчике, информация о других пакетах, которые необходимы для того, чтобы данное ПО корректно работало (чаще всего это необходимые данному приложению библиотеки), контрольные суммы, информация о том, как правильно сконфигурировать пакет, и как его корректно удалить, если необходимость в его использовании отпала.

Пакет обычно представляет собой один архивный файл, в котором содержится как само устанавливаемое программное обеспечение, так и необходимая служебная информация (мета-информация). Иногда эта мета-информация содержится не в самом пакете, а во внешней базе данных. Но для того, чтобы этой информацией воспользоваться, необходима еще какая-то программа установки, которая инсталлирует приложение из пакета в систему, используя по мере необходимости мета-информацию пакета. Очевидно, что эта программа сильно зависит от того, какая именно мета-информация содержится в пакете и как она организована. Таким образом и получилось, что создатели некоторых дистрибутивов разработали каждый свою структуру пакетов и свои специализированные средства управления пакетами, которые позволяли бы установить программу из пакета, используя содержащуюся в нем мета-информацию.

Система управления пакетами - это набор инструментов, предназначенных для автоматизации процессов установки, обновления, конфигурирования и удаления пакетов программного обеспечения определенного формата.

Наиболее известными (или распространенными) системами управления пакетами являются:

• RPM/YUM — менеджер пакетов Red Hat. Сейчас аббревиатура RPM расшифровывается обычно рекурсивно (RPM = RPM Package Manager), но первоначально ее расшифровывали как менеджер пакетов Red Hat (Red Hat Package Manager), поскольку разработана она была для дистрибутива Red Hat. В настоящее время она используется и во многих других дистрибутивах.
• dpkg/APT — система управления пакетами *.deb дистрибутива Debian, тоже портированная в настоящее время в другие дистрибутивы. Пакеты .deb представляют собой просто два tar-архива, сжатых с помощью gzip: в одном архиве содержится управляющая информация, в другом - данные. Стандартным средством управления такими пакетами является консольная программа dpkg, дополненная оболочкой APT (Advanced Packaging Tool).
• tgz или tar.gz — стандартный набор из двух программ tar + gzip, иногда дополненный некоторыми дополнительными управляющими файлами. Используется в дистрибутиве Slackware и некоторых других, не обеспечивает разрешения зависимостей. От Source-based дистрибутивов эта система отличается тем, что внутри tar.gz-архивов находятся заранее скомпилированные программы.
• система портежей дистрибутива Gentoo, которая представляет собой набор файлов ebuild, содержащих информацию о том, как получить (из любых доуступных источников - сети, локального диска и т.д.), скомпилировать и установить пакет в системе Gentoo, используя консольную команду emerge. Обычно пакет ПО в этом случае содержит исходные коды программ, и приложение компилируется прямо в процессе инсталляции, за счет чего оптимизируется для конкретной машины. Хотя этим способом могут устанавливаться и заранее откомпилированные программы, но такой вариант используется только в исключительных случаях, например, при инсталляции системы на очень медленные машины.
• YaST - утилита, разработанная Novell и используемая в дистрибутиве SuSE.

Компиляцию пакетов из исходных кодов тоже можно рассматривать как один из вариантов системы управления пакетами. От перечисленных выше систем он отличается только тем, что пакеты ПО в source-based дистрибутивах почти не содержат в своем составе заранее скомпилированных программ (кроме тех, которые абсолютно необходимы, типа ядра и компилятора), так что единственный способ установки нового пакета заключается в непосредственой компиляции его из исходных кодов.

Наиболее распространенным средством управления пакетами программного обеспечения остается программа RPM. Правда, она обладает тем недостатком, что задача разрешения зависимостей ложится в основном на плечи пользователя. Программа RPM только сообщает, что таких-то пакетов в системе не достает, а их поиск и установку пользователь должен выполнить самостоятельно. Поэтому многие основанные на RPM дистрибутивы сейчас используют также заимствованный из Debian инструмент APT, который появляется иногда и под другими именами. Дебиановский DEB и TGZ из Slackware (и его производные) тоже распространены достаточно широко. Кроме названных были изобретены еще несколько средств управления пакетами. Примерами могут служить SLP из дистрибутива Stampede, который имеет несколько интересных особенностей, и система управления пакетами дистрибутива JBLinux.

Таблица 1, заимствованная с сайта DistroWatch.com, показывает распространенность различных систем управления пакетами. Имейте в виду, что в отличие от аналогичной таблицы на DistroWatch, я не ставил задачу перечислить в правом столбце таблицы все дистрибутивы, использующие тот или иной способ управления пакетами, а привел только по несколько примеров.

Таблица 1.

Система управления пакетами

Число дистрибутивов, использующих эту систему

Примеры дистрибутивов

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

5. Сценарии начальной загрузки

Для начала давайте вспомним, что существует два разных стиля начальной загрузки операционной системы типа UNIX, происхождение которых уходит корями в историю развития UNIX-систем: так называемый стиль BSD (используемый также в таких системах как FreeBSD, NetBSD и OpenBSD), и стиль System V (или стиль ATT). Различие между ними проявляется в организации и размещении стартовых сценариев (скриптов), обеспечивающих управление процессами загрузки системы. В классических BSD-системах эти файлы хранятся в каталоге /etc и их имена начинаются с префикса "rc". В системах семейства System V файлы сценариев располагаются в каталоге /etc/init.d, а ссылки на них созданы в каталогах /etc/rc0.d, /etc/rc1.d и т.д. Второй вариант организации является более четким и позволяет аккуратнее выполнять останов системы. Если вы хотите подробнее узнать о различиях в двух названных стилях загрузки, прочитайте главу 2 книги [6].

Большая часть дистрибутивов Linux использует стиль System V. К этому классу относятся Debian, все клоны Red Hat, включая Mandrake и российские дистрибутивы ASPlinux и ALT Linux. В стиле BSD организована загрузка в дистрибутиве Slackware и его производных. Однако тот или иной стиль сценариев начальной загрузки выдерживается не очень четко. К примеру, структура каталогов, в которых хранятся инициализационные скрипты, в основных дистрибутивах существенно различается:

Листинг 1.

/etc/init.d/-----символьная ссылка на /etc/rc.d/init.d/
/etc/rc.d/------скрипты rc, rc.sysinit и rc.local
         |
         /init.d/-----множество файлов-скриптов
         /rc0.d/-----символьные ссылки @K*.* и @S*.*
         /rc1.d/-----символьные ссылки @K*.* и @S*.*
         ...........
         /rc6.d/-----символьные ссылки @K*.* и @S*.*
         /rcS.d/-----символьные ссылки @K*.* и @S*.*

/etc/init.d/-----скрипты rc, rcS, reboot и множество других,
/etc/rc0.d/-----символьные ссылки @K*.* и @S*.*
    /rc1.d/-----символьные ссылки @K*.* и @S*.*
     ...........
    /rc6.d/-----символьные ссылки @K*.* и @S*.*
    /rcS.d/-----символьные ссылки @K*.* и @S*.*

/etc/rc.d/--скрипты rc.0, rc.4, rc.6, rc.K, rc.M, rc.S, rc.local, 
	rc.syslog, rc.nfsd, rc.sysvinit, rc.netdevice, rc.keymap 
	и другие скрипты, имена которых имеют вид rc.*.

/etc/init.d/--скрипты с самыми разными именами.

/etc/rc.d/------символьная ссылка на /etc/init.d/
/etc/init.d/----множество файлов с разными именами, в частности boot.*
           /boot.d/----символьные ссылки @K*.* и @S*.* 
           /rc0.d/-----символьные ссылки @K*.* и @S*.*
           /rc1.d/-----символьные ссылки @K*.* и @S*.*
           ...........
           /rc6.d/-----символьные ссылки @K*.* и @S*.*
           /rcS.d/-----символьные ссылки @K*.* и @S*.*

Как видите, даже в Red Hat и Debian, которые следуют стилю System V, структура каталогов несколько отличается. А SuSE, хотя и происходит от Slackware, движется в сторону стиля System V, по крайней мере в организации структуры каталогов. А вот Red Hat, наоборот, завел скрипт rc.local, напоминающий одноименный сценарий во FreeBSD. В процессе загрузки он выполняется последним. Правда, в последних версиях Red Hat и Fedora Core этот скрипт "пустой", то есть практически не используется. И авторы книги [6] не советуют добавлять в него собственные команды, рекомендуя лучше воспользоваться средствами System V.

Но структура каталогов и названия инициализационных скриптов, может быть, и не самое главное. Как известно, в процессе начальной загрузки системы вначале загружается ядро, которое запускает процесс init, всегда имеющий идентификатор 0. Процесс init выполняет инструкции, заданные в файле /etc/inittab. В листинге 2 приведены выдержки из файла /etc/inittab для нескольких дистрибутивов. Приводится не полный текст файла /etc/inittab, а только по 4 группы самых важных строк, определяющих процесс загрузки. Во всех дистрибутивах кроме приведенных инструкций определяются еще действия по комбинации клавиш ++ и выполняется запуск виртуальных терминалов (только в Fedora Core и SuSE для этого вызываются процессы mingetty, в Gentoo и Slackware - agetty, в Knoppix - /bin/bash -login).

Листинг 2.

id:3:initdefault:

# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit

l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6

x:5:respawn:/etc/X11/prefdm -nodaemon

id:5:initdefault: 
# Boot-time system configuration/initialization script. 
si::sysinit:/etc/init.d/rcS 
# What to do in single-user mode. 
~~:S:respawn:/bin/bash -login >/dev/tty1 2>&1