Differences between revisions 1 and 9 (spanning 8 versions)
Revision 1 as of 2008-07-21 22:48:00
Size: 9954
Editor: eSyr
Comment:
Revision 9 as of 2008-07-28 11:30:10
Size: 25712
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
Переходим к пакетам. Это двольно забавная штука. Откуда взялся пакет. Он завёлся не от сырости, и в подавляющ. числе случаев вы не ск. с сайта прдукта, а с сайта дистр. Он случился птому, чт есть ментейнер, котрому инт. пргрю продукт, скачал его, оформил его в соотв. с полиси и положил в репозитрий. В итоге появились в репзитории две вещи --- src.rpm с исх. пргр. продуктом, патчами, дополн. картинками... и пакет с бинарниками. Пакет, который вы нашли в хранилище, адаптирван к семейству ОС, сделанных на сотв. ветке. Это озн., что люди, кгда планируют пакет, могут восп. тем, чт все каталоги стандартизирваны. Есть FHS, где прписано, что где должно лежать. Для того, чотбы уст. прогр. продукт., усл. говоря, дост. его разархивировать неглядя. В первую чередь, для уст. продукта дст. его просто рахзархивировать (cpio). Что мы сделали: мы скачали пакет с сайта, натравили утилиту, которая преб. его в cpio-архив, которая его разжимает и уд. доп. инф, и пакет. предст. сбй просто архив. Для того, чтобы уст. прогр. продукт, его надо разарх. Это сделает уст. Сразу возн. впрс, что делать, если есть ещё дин прогр. продукт, если там тже есть /usr/bin/zip? На данном этапе лектор отв. вопросом на вопрс: а как такое случилось? У нас есть хранилище, в котором два конфл. пакета, и мы мжем отследить, что два прогр. продукта кладут дин прогр. файл. Блее того, есть ситуации, когда конфл. предпочтителен, пск. такие прдукты делают дно и то же. Было бы норм., если пкет это архив, более того, есть slackware, где именно так. Чего не хватает в утв., что уст. это разархивация. А что такое удаление? Это разрахивация. Т есть, при уст. надо регистрировать сам факт уст. и уст. файлы. Эту функцию делает программа rpm: rpm query -f /usr/bin/zip. Обратите внимание, чт в репзитории уже более новый пакет. Куда rpm смтрит? В каую-то бд, где она это записывет. Переходим к пакетам. Обратимся к истории появления пакетов. Итак, в подавляющем большинстве случаев вы скачиваете его не с сайта продукта, а берёте из хранилища, которое поддерживается сообществом. Там он образовался потому, что есть ментейнер, котрому интересно иметь под рукой этот программный продукт; он скачал исходные тексты, оформил их в соответствии с дисциплиной сборки программных продуктов в хранилище, собрал, т.е. получил бинарный продукт. В результате в хранилище появились две вещи: то, что называется пакет с исходным кодом, src.rpm (авторские исходники + инструкция по сборке + так называемые патчи, т.е. модификации, накладываемые на авторские исходники + какие-то дополнительные файлы, которые мейнтейнер посчитал нужным вставить в результирующий программный продукт) и пакет с бинарными файлами.
Line 5: Line 5:
В момент регистр. для каждго файла зап. контр. сумма. Это нужно затем, чтбы прверить, изм. файл или нет? Идея проверки в след.: предп., что файл конфигурационный. В этм случае внутр. пакета помеч., чт файл конф., и если при уд. пакета выясн, что файл изменился, то он не удаляется, а переименовывается (в *.rpmsafe). При обн. новые конф. файлы кладутся как (*.rpmnew). На самм деле, этго ещё ндеост., поск. часто бывает, чт при уст. и уд. пакета надо вып. не только действия с файлами, но и доп. действия с системой. НапримеР, уст. mod_php. Было бы непл. ег не только уст, но и перезап. вебсервер. Или при уст. ведсервера надо добавить польз. apache. Бывает, чт онадо вып. специф. для пакеты действия. Это называется предуст. и постуд. сценарии. В альте их 4 (перед уст., после уст., перед уд., после уд.), в дебиане 7. Пример: rpmquery --scripts dhcp-server Пакет, который Вы нашли в хранилище, адаптирован к использованию в семействе операционных систем, сделанных на основе соответствующей ветки. Это означает, что люди, когда планируют пакет, могут воспользоваться тем, что в Вашем GNU/Linux все каталоги стандартизированы. Существует FHS, где прописано, в каком каталоге что должно лежать. Таким образом, для того, чтобы установить заранее протестированный и адаптированный программный продукт, достаточно его разархивировать. В отличие от Windows, где программный продукт --- это инсталлятор, т.е. программа, которую вы запускаете, и она делает нечто малопонятное (лектор удачто обозначил это непонятное словосочетанием "подозрительная кутерьма"), в GNU/Linux пакет --- это архив, и для того, чтобы его установить, достаточно его просто разархивировать:
{{{
[george@class305 ~]$ 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/ --- страница помощи. Пусть вас не смущает точка в начале - это специально для таких умников, как мы: если бы мы его сейчас разархивировали, он бы разархивировался в текущий каталог, а не в корень, и не прибил бы наш зип. Для того, чтобы установить программный продукт, его надо только разархивировать. Это за нас сделает установщик. Так что ничего тайного здесь нет; всё стандартизовано. Сразу возникает вопрос, что делать, если есть ещё один пакет, в котором тоже есть файл /usr/bin/zip? Лектор отвечает вопросом на вопрос: а как такое случилось? У нас есть хранилище, в котором все эти пакеты лежат одновременно. Чтобы устроить так, чтобы там лежали два конфликтующих по файлам (устанавливающих файл с одним и тем же именем) пакета, надо принять такое решение, потому что мы можем отследить, что два программных продукта направляют в одно и то же место два файла с одинаковыми именами. Более того, есть ситуации, когда такой конфликт предпочтителен, чтобы нельзя было поставить два программных продукта, которые делают одно и то же. Было бы нормально, если пакет это архив, более того, есть slackware, где именно так.
Line 7: Line 26:
На самом деле, свйства пакетов кк сущн. заканчиваются и нач. не менее важные. Пакет это такой архив, который рег. в системе при уст и вып. сценарии. Здесь возн. два вопроса: про конфл. и зависимости. Неск. раз гворилось за этот блок лекций, что допустим при исп. дин. библ. резко повышается убство для разрабтчика. В-первых, файл занимает меньше места, во-втрых, n файлов занимают меньше места, в-третьих, все ни польз. дной и тй же библ.. Это имеет обр. св-во --- при наличии ошибки вероятность нахожд ошибки в сотв. кол. раз выше. Но становится вопрос --- в какой пакет длжна вхдить дин. библитека, которой польз. много прогр. продуктов? Поск. мы можем пост. то один продукт, то другой, то логично включить его в каждый прогр. прдукт, но это ведёт к тому же, что и при статическй сборке. Особенно, если мы знаем, что нет никаких огр. к доступу к пакетам. Поэтому ндао в кач. осн. вариант принимать второй -- если некая группа библ. исп. рядом разного по, то он кладётся отд. пакетом. ==== Регистрация ====
Чего не хватает в утверждении, что установка програмного продукта это разархивация? Нужно ответить на вопрос, что такое удаление. Это удаление вот этих самых (которые разархивированные) файлов. Это значит, что при установке надо регистрировать сам факт установки и список установленных файлов, и если мы захотим удалить программный продукт, мы обратимся к базе данных, где написано, какие файлы какому пакету принадлежат. Эту функцию делает программа rpm:
{{{
$ rpmquery -f /usr/bin/zip
zip-2.32-alt1.0
}}}
Обратите внимание, что здесь присутствуют разные пакеты: в системе установлен zip-2.32-alt1.0, а в апдейтах (откуда был скачан пакет из предыдущего примера) лежит zip-2.32-alt2.S40.1. Куда rpm смотрит? В какую-то базу данных установленных пакетов.
Line 9: Line 34:
# В мастер входит порядка 400 пргр. прдуктов, которые рег. иконки. ==== Контрольная сумма ====
При регистрации происходят еще два важных процесса. Во-первых, для каждого файла запоминается (или берётся из пакета) контрольная сумма. Это необходимо, чтобы определить, изменился ли файл, входящий в пакет, или нет. Зачем это нужно? Допустим, у вас есть программа pswd, с её помощью вы меняете пароли, и в какой-то момент вы запускаете утилиту, которая проверяет, не изменилась ли контрольная сумма программы pswd и выясняется, что она изменилась. Тут есть основания рвать на себе волосы, посыпать голову пеплом, сносить операционную систему и ставить её заново, потому что если кто-то подменил вам программу pswd, значит, он чего-то от вас хотел. Это, правда, отдельный разговор, потому что умный человек подменит ещё и запись в базе данных относительно контрольной суммы... Вторая идея проверки контрольной суммы файла и вообще всякой информации файла состоит в следующем: предположим, что файл конфигурационный, то есть такой, который (предполагается) вы будете менять. В этом случае внутри пакета он помечается как конфигурационный, при регистрации от него считается контрольная сумма, и если при удалении пакета выясняется, что этот файл был модифицирован, то он не удаляется, а переименовывается. Почему? Например, вы поставили вебсервер, долго его настраивали, редактируя конфигурационный файл. Потом пришлось его удалить. Потом вы снова поставили вебсервер. Было бы неплохо, чтобы в момент удаления конфигурационный файл, который вы двое суток редактировали, никуда не делся. Он никуда и не денется, а переименуется в *.rpmsafe. Обратная ситуация: вы поставили пакет, редактируете конфигурационный файл, а потом этот пакет обновили. Было бы неплохо, чтобы тот конфигурационный файл, который вы редактируете, остался с тем же именем, а тот, который входит в пакет, рядом положился. Такое тоже есть; такой конфигурационный файл кладётся с именем *.rpmnew. Это в случае альта, где испоьзуется установщик rpm. В случае дебиана всё ещё интереснее, есть специальный конфигурационный скрипт, и дебиан полиси говорит, что после того, как вы производите обновление, миграция со старого конфига в новый конфиг должна произойти сама.
Line 11: Line 37:
Вт у нас неск. тысяч пакетов в исизифе, неск. тысяч в дистр. Всё это замечательно, но как же быть с установкой? чтбы уст. гимп, надо уст. кучу пакетов, кторые ему нужны, а им в свю чередь тоже нужны и так далле. Да, есть такое понятие как зависимсть пакетов, и пакет, имеющ. зависимсти, не мжет быть уст., пока зависимости не удовл. ==== Сценарии ====
На самом деле, этого ещё недостаточно, поскольку часто бывает, что при установке и удалении пакета надо выполнять не только разархивацию, но и дополнительные действия с системой. Например, вы устанавливаете вебсервер, и к нему - модуль его настроек, например, mod_php. Было бы неплохо не только его установить, но и модифицировать конфигурационные файлы, если это нужно, и перезапустить вебсервер. Или при установке вебсервера процесс должен выполняться от лица специального пользователя apache, и этого пользователя надо добавить в систему, а когда вы удаляете вебсервер, этого пользователя нужно то ли удалить, то ли не удалять. Так или иначе, действий, описанных выше, недостаточно. Бывает, что при установке или удалении пакета надо выполнить специфические для этого пакета действия. Это называется сценарии (например, предустановочные). В альте их 4 (перед установкой пакета, после установки пакета, перед удалением пакета, после удаления пакета), в дебиане 7. Пример:
{{{
[george@class305 ~]$ 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
Line 13: Line 49:
Осталась проблема кнфликтов. Этот конфликт паразитный --- было бы непл, чтобы два ментейнера договорились, как они сит. будут разруливать. Есть инструмент, наз. альтернативы, которые делает слкдующее: ... . Наиболее частый пример --- cdrecordю Он сущ. в двух ипостасях, один кторый пишет ..., и cdrecord, которое пишет сообщество. Проблема в том, что у этих программ уже разный синт. ключей. Осталось тольк выясн., кто есть cdrecord. Если в сист. стоят оба пакета, то в /usr/bin лежит симлинк. Симлинк всегда смотрит на альтернативы, а спец. утилита в alternatives позв. переключать либо туда, либ туда. # 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
Line 15: Line 55:
Пр конфликты. Бывает, чт конфл. над обеспечить. Вот есть два почт. сервера, и ба хотите устанвить. По-хорошему, этго делать не надо. При этом, предп. ситуацию, что конф. по файлам не сущ. Было бы неплохо этот конфл. вписать в пакеты заранее. Это делается след. образом: каждый пакет объявл, какие функции он обеспечивает. Если вы попытаетесь уст. два пакета, кторые обесп. один. функц., вам ничег не дадут сделать. # 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 раз выше. Но возникает вопрос - в какой пакет должна входить динамическая библитека, которой пользуются много програмных продуктов, находящихся в разных пакетах? Есть два варианта ответа. С одной стороны, поскольку мы можем поставить то один програмный продукт, то другой, то логично включить свою копию динамической библиотеки внутрь каждого пакета, но это ведёт к тому же, что происходит при статическй сборке, только хуже, поскольку файлов больше. С каждым пакетом будут ездить собственные динамические библиотеки, и получится, как в виндоусе - разноверсица, которая там - одна из самых страшных болезней. Так что это неприемлемо. Особенно, если мы заранее знаем, что нет никаких ограничений к информационному доступу к пакетам. Поэтому надо в качестве основного варианта принимать второй - если некая разделяемая библиотека или группа однотипных разделяемых библиотек используется несколькими програмными продуктами, то она лежит в отдельном пакете. То есть, не каждый пакет сам по себе является програмным продуктом, в том смысле, что если это, например, набор библиотек, то иконок от них вы не увидите.

Итак, вот у нас несколько тысяч пакетов в сизифе, несколько тысяч в большом дистрибутиве, несколько сотен в малом. Всё это замечательно, но как же быть с установкой? Ведь чтобы установить тот же гимп, надо установить ещё кучу пакетов, которые он требует, а им в свою очередь тоже нужны какие-то другие пакеты и так далее. Ответ на этот вопрос простой: есть такое понятие как зависимость пакетов, и пакет, содержащий зависимсти на другие, не может быть установлен, пока другие пакеты тоже не установлены.

==== Конфликты ====

Осталась рассмотреть проблему конфликтов. Может получиться, что два разных пакета содержат один и тот же файл (т.е. тот, который будет помещён в одну и ту же директорию под одним и тем же названием). Этот конфликт паразитный - было бы неплохо, чтобы два ментейнера договорились, как они будут разруливать эту ситуацию. Наиболее частый пример - cdrecord. Это утилита для записи лазерных дисков с командной строки. Он существует в двух ипостасях, один, который пишет Йорг Шиллинг, и другой, который пишет сообщество, которое в какой-то момент взяло исходный код и начало модифицировать его самостоятельно (потому, что Йорг боится патентных преследований и отказывается распространять под свободной лицензией версию cdrecord'а, которая умеет писать на dvd, который в некоторых странах как таковой защищён патентом). Поэтому есть два варианта cdrecord'а, один называется cdrecord classic, а другой - dvdrecord. Проблема в том, что у этих программ уже разный синтаксис ключей, и вы можете захотеть, чтобы у вас был cdrecord classic, чтобы работали какие-то штуки, которые используют его ключи. Осталось только выяснить, кто из них называется cdrecord. Если в системе стоят оба пакета, то в /usr/bin лежит символьная ссылка, которая всегда смотрит на один из двух вариантов, а специальная утилита alternatives позволяет переключать либо туда, либо сюда.

Чтобы добить тему конфликтов. Бывает, что конфликт необходимо обеспечить. Например, у вас есть два почтовых сервера, и вы оба хотите установить. По-хорошему, этого делать не надо, поскольку тот и другой будут пытаться принимать соединения по двадцать пятому порту, и первый из них, который запустится, будет это делать, а второй не сможет это сделать и будет выдавать ошибку. При этом, предположим ситуацию, что конфликта по файлам между этими пакетами не существует. Было бы неплохо этот конфликт вписать в пакеты заранее. Это делается следующим образом: каждый пакет объявляет, какие функции он обеспечивает. Если вы попытаетесь установить два пакета, которые обеспечивают одинаковую функциональность, то есть у них поле provides где-то пересекается, вам ничего не дадут сделать, даже если конфликта по файлам нет, потому что так изначально было задумано, ибо эти два пакета изначально не функционируют в системе. Так что конфликт может быть не только результатом недосмотра двух мейнтейнеров, но и сознательно сделанной мейнтейнерами штукой, не позволяющей вам убить или наполнить мусором систему.
Line 23: Line 92:
|| 0 || 1 || 1 || 1 || || 1 || ConstantinYershow, ОльгаТочилкина, MaximByshevskiKonopko || || || || 26 || 1 || 1 || 1 || || 1 || ConstantinYershow, ОльгаТочилкина, MaximByshevskiKonopko || || ||

Пакет

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

Пакет, который Вы нашли в хранилище, адаптирован к использованию в семействе операционных систем, сделанных на основе соответствующей ветки. Это означает, что люди, когда планируют пакет, могут воспользоваться тем, что в Вашем GNU/Linux все каталоги стандартизированы. Существует FHS, где прописано, в каком каталоге что должно лежать. Таким образом, для того, чтобы установить заранее протестированный и адаптированный программный продукт, достаточно его разархивировать. В отличие от Windows, где программный продукт --- это инсталлятор, т.е. программа, которую вы запускаете, и она делает нечто малопонятное (лектор удачто обозначил это непонятное словосочетанием "подозрительная кутерьма"), в GNU/Linux пакет --- это архив, и для того, чтобы его установить, достаточно его просто разархивировать:

[george@class305 ~]$ 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/ --- страница помощи. Пусть вас не смущает точка в начале - это специально для таких умников, как мы: если бы мы его сейчас разархивировали, он бы разархивировался в текущий каталог, а не в корень, и не прибил бы наш зип. Для того, чтобы установить программный продукт, его надо только разархивировать. Это за нас сделает установщик. Так что ничего тайного здесь нет; всё стандартизовано. Сразу возникает вопрос, что делать, если есть ещё один пакет, в котором тоже есть файл /usr/bin/zip? Лектор отвечает вопросом на вопрос: а как такое случилось? У нас есть хранилище, в котором все эти пакеты лежат одновременно. Чтобы устроить так, чтобы там лежали два конфликтующих по файлам (устанавливающих файл с одним и тем же именем) пакета, надо принять такое решение, потому что мы можем отследить, что два программных продукта направляют в одно и то же место два файла с одинаковыми именами. Более того, есть ситуации, когда такой конфликт предпочтителен, чтобы нельзя было поставить два программных продукта, которые делают одно и то же. Было бы нормально, если пакет это архив, более того, есть slackware, где именно так.

Регистрация

Чего не хватает в утверждении, что установка програмного продукта это разархивация? Нужно ответить на вопрос, что такое удаление. Это удаление вот этих самых (которые разархивированные) файлов. Это значит, что при установке надо регистрировать сам факт установки и список установленных файлов, и если мы захотим удалить программный продукт, мы обратимся к базе данных, где написано, какие файлы какому пакету принадлежат. Эту функцию делает программа rpm:

$ rpmquery -f /usr/bin/zip
zip-2.32-alt1.0

Обратите внимание, что здесь присутствуют разные пакеты: в системе установлен zip-2.32-alt1.0, а в апдейтах (откуда был скачан пакет из предыдущего примера) лежит zip-2.32-alt2.S40.1. Куда rpm смотрит? В какую-то базу данных установленных пакетов.

Контрольная сумма

При регистрации происходят еще два важных процесса. Во-первых, для каждого файла запоминается (или берётся из пакета) контрольная сумма. Это необходимо, чтобы определить, изменился ли файл, входящий в пакет, или нет. Зачем это нужно? Допустим, у вас есть программа pswd, с её помощью вы меняете пароли, и в какой-то момент вы запускаете утилиту, которая проверяет, не изменилась ли контрольная сумма программы pswd и выясняется, что она изменилась. Тут есть основания рвать на себе волосы, посыпать голову пеплом, сносить операционную систему и ставить её заново, потому что если кто-то подменил вам программу pswd, значит, он чего-то от вас хотел. Это, правда, отдельный разговор, потому что умный человек подменит ещё и запись в базе данных относительно контрольной суммы... Вторая идея проверки контрольной суммы файла и вообще всякой информации файла состоит в следующем: предположим, что файл конфигурационный, то есть такой, который (предполагается) вы будете менять. В этом случае внутри пакета он помечается как конфигурационный, при регистрации от него считается контрольная сумма, и если при удалении пакета выясняется, что этот файл был модифицирован, то он не удаляется, а переименовывается. Почему? Например, вы поставили вебсервер, долго его настраивали, редактируя конфигурационный файл. Потом пришлось его удалить. Потом вы снова поставили вебсервер. Было бы неплохо, чтобы в момент удаления конфигурационный файл, который вы двое суток редактировали, никуда не делся. Он никуда и не денется, а переименуется в *.rpmsafe. Обратная ситуация: вы поставили пакет, редактируете конфигурационный файл, а потом этот пакет обновили. Было бы неплохо, чтобы тот конфигурационный файл, который вы редактируете, остался с тем же именем, а тот, который входит в пакет, рядом положился. Такое тоже есть; такой конфигурационный файл кладётся с именем *.rpmnew. Это в случае альта, где испоьзуется установщик rpm. В случае дебиана всё ещё интереснее, есть специальный конфигурационный скрипт, и дебиан полиси говорит, что после того, как вы производите обновление, миграция со старого конфига в новый конфиг должна произойти сама.

Сценарии

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

[george@class305 ~]$ 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 раз выше. Но возникает вопрос - в какой пакет должна входить динамическая библитека, которой пользуются много програмных продуктов, находящихся в разных пакетах? Есть два варианта ответа. С одной стороны, поскольку мы можем поставить то один програмный продукт, то другой, то логично включить свою копию динамической библиотеки внутрь каждого пакета, но это ведёт к тому же, что происходит при статическй сборке, только хуже, поскольку файлов больше. С каждым пакетом будут ездить собственные динамические библиотеки, и получится, как в виндоусе - разноверсица, которая там - одна из самых страшных болезней. Так что это неприемлемо. Особенно, если мы заранее знаем, что нет никаких ограничений к информационному доступу к пакетам. Поэтому надо в качестве основного варианта принимать второй - если некая разделяемая библиотека или группа однотипных разделяемых библиотек используется несколькими програмными продуктами, то она лежит в отдельном пакете. То есть, не каждый пакет сам по себе является програмным продуктом, в том смысле, что если это, например, набор библиотек, то иконок от них вы не увидите.

Итак, вот у нас несколько тысяч пакетов в сизифе, несколько тысяч в большом дистрибутиве, несколько сотен в малом. Всё это замечательно, но как же быть с установкой? Ведь чтобы установить тот же гимп, надо установить ещё кучу пакетов, которые он требует, а им в свою очередь тоже нужны какие-то другие пакеты и так далее. Ответ на этот вопрос простой: есть такое понятие как зависимость пакетов, и пакет, содержащий зависимсти на другие, не может быть установлен, пока другие пакеты тоже не установлены.

Конфликты

Осталась рассмотреть проблему конфликтов. Может получиться, что два разных пакета содержат один и тот же файл (т.е. тот, который будет помещён в одну и ту же директорию под одним и тем же названием). Этот конфликт паразитный - было бы неплохо, чтобы два ментейнера договорились, как они будут разруливать эту ситуацию. Наиболее частый пример - cdrecord. Это утилита для записи лазерных дисков с командной строки. Он существует в двух ипостасях, один, который пишет Йорг Шиллинг, и другой, который пишет сообщество, которое в какой-то момент взяло исходный код и начало модифицировать его самостоятельно (потому, что Йорг боится патентных преследований и отказывается распространять под свободной лицензией версию cdrecord'а, которая умеет писать на dvd, который в некоторых странах как таковой защищён патентом). Поэтому есть два варианта cdrecord'а, один называется cdrecord classic, а другой - dvdrecord. Проблема в том, что у этих программ уже разный синтаксис ключей, и вы можете захотеть, чтобы у вас был cdrecord classic, чтобы работали какие-то штуки, которые используют его ключи. Осталось только выяснить, кто из них называется cdrecord. Если в системе стоят оба пакета, то в /usr/bin лежит символьная ссылка, которая всегда смотрит на один из двух вариантов, а специальная утилита alternatives позволяет переключать либо туда, либо сюда.

Чтобы добить тему конфликтов. Бывает, что конфликт необходимо обеспечить. Например, у вас есть два почтовых сервера, и вы оба хотите установить. По-хорошему, этого делать не надо, поскольку тот и другой будут пытаться принимать соединения по двадцать пятому порту, и первый из них, который запустится, будет это делать, а второй не сможет это сделать и будет выдавать ошибку. При этом, предположим ситуацию, что конфликта по файлам между этими пакетами не существует. Было бы неплохо этот конфликт вписать в пакеты заранее. Это делается следующим образом: каждый пакет объявляет, какие функции он обеспечивает. Если вы попытаетесь установить два пакета, которые обеспечивают одинаковую функциональность, то есть у них поле provides где-то пересекается, вам ничего не дадут сделать, даже если конфликта по файлам нет, потому что так изначально было задумано, ибо эти два пакета изначально не функционируют в системе. Так что конфликт может быть не только результатом недосмотра двух мейнтейнеров, но и сознательно сделанной мейнтейнерами штукой, не позволяющей вам убить или наполнить мусором систему.


Сведения о ресурсах

Готовность (%)

Продолжительность (ак. ч.)

Подготовка (календ. ч.)

Полный текст (раб. д.)

Предварительные знания

Level

Maintainer

Start date

End date

26

1

1

1

1

ConstantinYershow, ОльгаТочилкина, MaximByshevskiKonopko


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

PspoClasses/080720/02Package (last edited 2008-10-09 18:49:05 by MaximByshevskiKonopko)