Пакет
Рассмотрим свойства пакетов. Обратимся сначала к истории их появления. Итак, в подавляющем большинстве случаев Вы скачиваете пакет не с сайта продукта, а берёте из хранилища, которое поддерживается сообществом. В хранилище пакет появился благодаря ментейнеру, который скачал исходные тексты, оформил их в соответствии с дисциплиной сборки программных продуктов в хранилище, собрал, т.е. получил бинарный продукт. В результате в хранилище появились: пакет с исходным кодом, src.rpm (авторские исходники + инструкция по сборке + так называемые патчи, т.е. модификации, накладываемые на авторские исходники + некие дополнительные файлы, которые мейнтейнер посчитал нужным вставить в результирующий программный продукт) и пакет с бинарными файлами.
Пакет, который Вы нашли в хранилище, адаптирован к использованию в семействе операционных систем, сделанных на основе соответствующей ветки. Это означает, что люди, планирующие пакет, могут воспользоваться тем, что в дистрибутиве все каталоги стандартизированы согласно Filesystem Hierarchy Standard (FHS) --- стандарту, описывающему, какого рода файлы должны находиться в том или ином каталоге. Таким образом, для того, чтобы установить заранее протестированный и адаптированный программный продукт, достаточно распаковать архив. В отличие от операционной системы Windows, где программный продукт --- это инсталлятор, т.е. программа, которая делает нечто малопонятное, в результате которого в системе что-то где-то появляется и вероятно начинает работать, в нашем случае пакет --- это просто архив, и для того, чтобы его установить, достаточно его просто распаковать:
[user@demo ~]$ rpm2cpio zip-2.32-alt2.S40.1.i586.rpm | cpio -itv -rwxr-xr-x 1 root root 66808 Jun 25 17:16 ./usr/bin/zip -rwxr-xr-x 1 root root 26616 Jun 25 17:16 ./usr/bin/zipcloak -rwxr-xr-x 1 root root 22548 Jun 25 17:16 ./usr/bin/zipnote -rwxr-xr-x 1 root root 26580 Jun 25 17:16 ./usr/bin/zipsplit drwxr-xr-x 2 root root 0 Jun 25 17:16 ./usr/share/doc/zip-2.32 -rw-r--r-- 1 root root 401 May 18 2006 ./usr/share/doc/zip-2.32/BUGS -rw-r--r-- 1 root root 77392 Jun 20 2006 ./usr/share/doc/zip-2.32/CHANGES -rw-r--r-- 1 root root 2692 Apr 10 2000 ./usr/share/doc/zip-2.32/LICENSE -rw-r--r-- 1 root root 42404 Jun 20 2006 ./usr/share/doc/zip-2.32/MANUAL -rw-r--r-- 1 root root 8674 Apr 14 2006 ./usr/share/doc/zip-2.32/README -rw-r--r-- 1 root root 3149 Feb 21 2005 ./usr/share/doc/zip-2.32/TODO -rw-r--r-- 1 root root 3382 Jun 20 2006 ./usr/share/doc/zip-2.32/WHATSNEW -rw-r--r-- 1 root root 19032 Apr 19 2000 ./usr/share/doc/zip-2.32/WHERE -rw-r--r-- 1 root root 12398 Jun 20 2006 ./usr/share/man/man1/zip.1.bz2 614 blocks
Итак, мы скачали пакет и применили к нему утилиту rpm2cpio, которая превратила его в cpio-архив. Во-первых, она его распаковывает, а во-вторых, удаляет метаинформацию, содержащуюся в пакете для установщика. Как уже было сказано выше, пакет представляет собой просто архив. Обратите внимание, что внутри пакета также соблюдаются требования стандарта FHS: в /usr/bin/ находятся бинарные файлы, в /usr/share/doc/ --- документация, в /usr/share/man/ --- страница помощи. Обратите внимание, что в начале пути стоит точка. Если бы мы его сейчас распаковали, он бы распаковался в текущий каталог, а не в корень, и не удалил бы наш зип. Итак, для того, чтобы установить программный продукт, по сути, надо лишь распаковать архив. Это за нас сделает установщик. Так что ничего тайного здесь нет; всё стандартизовано. Отметим, что в Slackware пакет представляет собой обычный tar-архив, что делает процесс установки ещё более простым.
Однако возникает вопрос: что делать, если есть ещё один пакет, в котором тоже есть файл /usr/bin/zip --- ведь если у нас стоял первый, при распаковке второго возникнет конфликт? Необходимо понять, как такое могло произойти. У нас есть хранилище, в котором все пакеты лежат одновременно. Чтобы сделать так, чтобы в нем находились два конфликтующих по файлам (устанавливающих файл с одним и тем же именем) пакета, нужно осознанно принять такое решение, потому что отследить, что два программных продукта направляют в одно и то же место два файла с одинаковыми именами, легко. Более того, есть ситуации, когда такой конфликт предпочтителен, об этом мы подробно расскажем ниже.
Регистрация
Однако установка программного продукта включается в себя не только распаковку архива. При установке пакетов нельзя забывать о том, что, возможно, нам придётся их в будущем удалить. Что такое удаление? Это удаление собственно разархивированных файлов. Это значит, что при установке происходит регистрация собственно факта установки и создаётся список установленных файлов. Таким образом, если мы захотим удалить программный продукт, мы обратимся к базе данных, где содержится информация о том, какие файлы тому или иному пакету принадлежат. Эту функцию выполняет программа rpm (rpmquery --- аналог вызова rpm -q):
[user@demo ~]$ rpmquery -f /usr/bin/zip zip-2.32-alt1.0
Обратите внимание, что здесь присутствуют разные пакеты: в системе установлен zip-2.32-alt1.0, а в апдейтах (раздел хранилища пакетов с рекомендуемыми обновлениями; оттуда был скачан пакет из предыдущего примера) лежит zip-2.32-alt2.S40.1. Существует некая база данных установленных пакетов, откуда rpm берёт информацию.
Контрольная сумма
При регистрации происходят ещё два важных процесса. Во-первых, для каждого файла запоминается (или берётся из пакета) контрольная сумма. Это необходимо, чтобы определить, изменился ли файл, входящий в пакет, или нет. Зачем это нужно? Допустим, у Вас есть программа passwd, с помощью которой изменяются пароли пользователей, и в какой-то момент Вы запускаете утилиту, которая проверяет, не изменилась ли контрольная сумма программы passwd и выясняется, что она изменилась. Это серьёзный повод для беспокойства и переустановки операционной системы, потому что если кто-то подменил вам программу passwd, безопасность Вашего компьютера под угрозой. Это, в принципе, отдельный разговор, потому что умный человек подменит ещё и запись в базе данных относительно контрольной суммы...
Вторая причина проверки контрольной суммы файла и вообще всякой информации файла состоит в следующем: предположим, что файл конфигурационный, то есть такой, который (предполагается, что) вы будете менять. В этом случае внутри пакета он помечается как конфигурационный, при регистрации считается его контрольная сумма. Если при удалении пакета выясняется, что этот файл был модифицирован, то он не удаляется, а переименовывается. Почему? Например, Вы установили Web-сервер, долго его настраивали, редактируя конфигурационный файл, после чего пришлось его удалить. Потом вы снова установили Web-сервер. Было бы неплохо, чтобы в момент удаления конфигурационный файл, который вы так долго редактировали, остался у Вас. Действительно, он не удалится, а переименуется в *.rpmsave. Обратная ситуация: вы поставили пакет, редактируете конфигурационный файл, а потом этот пакет обновили. Желательно, чтобы тот конфигурационный файл, который вы редактируете, остался с тем же именем, а тот, который входит в пакет, записался отдельно. Такое тоже есть: такой конфигурационный файл записывается с именем *.rpmnew. Это в случае с ALTLinux, где используется установщик rpm. В случае, скажем, c Debian всё сложнее, есть специальные конфигурационные скрипты, после того, как вы производите обновление, данные автоматически переписываются из старого конфигурационного файла в новый.
Сценарии
На самом деле, это ещё не всё, поскольку часто бывает, что при установке и удалении пакета надо выполнять не только распаковку пакета или удаление неких файлов, но и дополнительные действия с системой. Например, вы устанавливаете Web-сервер apache, и к нему --- какой-нибудь его модуль, например, mod_php. Было бы неплохо не только его установить, но и модифицировать конфигурационные файлы, если это нужно, и перезапустить Web-сервер. Опять же, процесс Web-сервера должен выполняться от лица специального пользователя apache, и этого пользователя надо добавить в систему, а когда вы удаляете этот Web-сервер, необходимо решить, нужно ли этого пользователя удалять. Так или иначе, действий, описанных выше, недостаточно. Бывает, что при установке или удалении пакета надо выполнить специфические для этого пакета действия. Эти действия называются сценариями (например, предустановочные сценарии). В дистрибутивах ALTLinux их 4 (перед установкой пакета, после установки пакета, перед удалением пакета, после удаления пакета), в Debian --- 7. Пример:
[user@demo ~]$ rpmquery --scripts dhcp-server
preinstall scriptlet (through /bin/sh):
/usr/sbin/useradd -r -n -g dhcp -d /var/lib/dhcp/dhcpd -s /dev/null -c 'The ISC DHCP server daemon' dhcpd >/dev/null 2>&1 ||:
/bin/rm -f /var/run/dhcpd.restart
# stop _old_ dhcpd if running
if [ $1 -eq 1 ] && [ -x /etc/rc.d/init.d/dhcpd ] && /etc/rc.d/init.d/dhcpd status >/dev/null 2>&1; then
/etc/rc.d/init.d/dhcpd condstop && touch /var/run/dhcpd.restart ||:
fi
# relocate dhcpd.conf
if [ ! -f /etc/dhcp/dhcpd.conf -a -f /etc/dhcpd.conf ]; then
/bin/mkdir -p /etc/dhcp
/bin/mv -v /etc/dhcpd.conf /etc/dhcp/
fi
# relocate dhcpd.leases
if [ ! -f /var/lib/dhcp/dhcpd/state/dhcpd.leases -a -f /var/lib/dhcp/dhcpd.leases ]; then
/bin/mkdir -p /var/lib/dhcp/dhcpd/state
/bin/mv -v /var/lib/dhcp/dhcpd.leases /var/lib/dhcp/dhcpd/state/
fi
if [ $1 = 0 ]; then
/bin/rm -f /var/lib/dhcp/dhcpd/lib/* /var/lib/dhcp/dhcpd/var/yp/binding/*
fi
postinstall scriptlet (through /bin/sh):
/etc/chroot.d/dhcpd.all
/usr/sbin/post_service dhcpd
if [ -f /var/run/dhcpd.restart ]; then
/bin/rm -f /var/run/dhcpd.restart
/etc/rc.d/init.d/dhcpd start ||:
fi
preuninstall scriptlet (through /bin/sh):
/usr/sbin/preun_service dhcpdИтак, пакет --- это такой архив, который при распаковке регистрируется в системе и, возможно, когда вы его устанавливаете и удаляете, выполняется какая-то группа сценариев. Рассмотрим теперь особенности функционирования пакетов. Речь здесь пойдет о зависимостях и конфликтах.
Зависимости
Как уже неоднократно говорилось выше, использование динамической библиотеки повышает удобство для разрабтчика. Во-первых, исполняемый файл, собранный с динамической библиотекой, занимает меньше места, во-вторых, n исполняемых файлов тоже занимают меньше места, поскольку библиотеки не входят в состав этих n файлов, в-третьих, все они пользуются одной и той же библиотекой, соответственно, можно рассчитывать на то, что любая программа, скажем, вычисляющая синус, вычисляет его правильно. Это, кстати, имеет обратное свойство: если в одной библиотеке есть ошибка, а ею пользуются 20 программ, вероятность возникновения ошибки в процессе работы в 20 раз выше, однако в некоторой степени это хорошо, потому что вероятность того, что вы эту ошибку вовремя исправите тоже в 20 раз выше. Однако возникает вопрос: в какой пакет должна входить динамическая библитека, которой пользуются много программных продуктов, находящихся в разных пакетах? Есть два варианта ответа.
С одной стороны, поскольку мы можем поставить то один програмный продукт, то другой, то логично включить свою копию динамической библиотеки внутрь каждого пакета. В таком случае мы теряем все преимущества динамической библиотеки, возвращаясь, по сути, к статической сборке, только файлов становится еще больше. С каждым пакетом будут поставляться собственные динамические библиотеки, их версии могут быть несогласованы, так что это неприемлемо, особенно, если мы заранее знаем, что нет никаких ограничений к информационному доступу к пакетам. Поэтому в качестве основного варианта нужно принимать второй: если некая разделяемая библиотека или группа однотипных разделяемых библиотек используется несколькими програмными продуктами, то она находится в отдельном пакете. Таким образом, не каждый пакет сам по себе является программным продуктом в обычном смысле.
Итак, вот у нас несколько тысяч пакетов в хранилище, несколько тысяч в большом дистрибутиве, несколько сотен в малом. Всё это замечательно, но как же быть с установкой? Ведь чтобы установить, например, графический редактор GIMP, надо установить ещё несколько пакетов, которые он требует, а им в свою очередь тоже нужны какие-то другие пакеты и так далее. Ответ на этот вопрос простой: есть такое понятие как зависимость пакетов, и пакет, содержащий зависимости на другие, не может быть установлен, пока другие пакеты тоже не установлены. Для работы с зависимостями пакетов применяется сущность над установщиком пакетов --- диспетчер пакетов, о котором будет рассказано позднее.
Конфликты
Осталась рассмотреть проблему конфликтов. Может получиться, что два разных пакета содержат один и тот же файл (т.е. тот, который будет помещён в одну и ту же директорию под одним и тем же названием). Этот конфликт паразитный - было бы неплохо, чтобы два ментейнера договорились, как они будут разруливать эту ситуацию. Наиболее частый пример --- cdrecord. Это утилита для записи лазерных дисков с использованием интерфейса командной строки. Она существует в двух вариантах: тот, который пишет Йорг Шиллинг, и тот, который пишет сообщество, которое в какой-то момент взяло исходный код и начало модифицировать его самостоятельно (потому, что Йорг боится патентных преследований и отказывается распространять под свободной лицензией версию cdrecord'а, которая может писать на dvd, который в некоторых странах защищён патентом). Поэтому есть два варианта cdrecord'а: один называется cdrecord classic, а другой - dvdrecord. Проблема в том, что у этих программ разный синтаксис ключей, и вы можете захотеть, чтобы у вас был cdrecord classic, чтобы работали какие-то штуки, которые используют его ключи. Осталось только выяснить, кто из них называется cdrecord. Если в системе стоят оба пакета, то в /usr/bin лежит символьная ссылка, которая всегда ведет в один из двух вариантов, а специальная утилита alternatives позволяет переключаться между ними.
Бывает так, что конфликт необходимо обеспечить. Например, у вас есть два почтовых сервера, и вы оба хотите установить. В прицнипе, этого делать не надо, поскольку оба они будут пытаться принимать соединения по двадцать пятому порту, и первый из них, который запустится, будет это делать, а второй не сможет это сделать и будет выдавать ошибку. Более того, предположим ситуацию, что конфликта по файлам между этими пакетами не существует. Однако рационально этот конфликт вписать в пакеты заранее. Это делается следующим образом: каждый пакет объявляет, какие функции он обеспечивает. Если вы попытаетесь установить два пакета, которые обеспечивают одинаковую функциональность, то есть у них поле provides в чем-то совпадает, вам ничего не дадут сделать, даже если конфликта по файлам нет. Таким образом, конфликт может быть не только результатом недосмотра двух мейнтейнеров, но и сознательно введенным механизмом, предотвращающим ошибочные действия.
Сведения о ресурсах
Продолжительность (ак. ч.) |
Подготовка (календ. ч.) |
Полный текст (раб. д.) |
Предварительные знания |
Level |
1 |
1 |
1 |
|
1 |