Администратор сам себя.

Сообщество вокруг дистрибутива

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

В случае дистрибутивов роль core team — определять стратегическое направление, в котором развивать дистрибутив, и не давать проявляться субъективным факторам, например ленивым или просто ушедшим на другую деятельность разработчикам. Необходимо, чтобы и веб-браузер был на уровне, и чтобы ядро ОС было достаточно защищённое и современное, а если какой-то сторонний человек, не входящий в core, и вообще изредка участвующий в этом сообществе, занимается ключевой частью дистрибутива, то может получиться такая ситуация: в ядре ОС давно обнаружены и исправлены ошибки, а в дистрибутиве все ещё находится старое.

Так вот, по отношению к дистрибутиву у core team сохраняются все те же функции, что и по отношению к обычной свободной программе, а понятие разработчика слегка размывается, т.к. основной фигурой на этом месте становится мейнтейнер, он же сопровождающий. Это человек, который имеет некоторую необходимость использовать программный продукт в рамках нашего дистрибутива, и эта необходимость настолько сильная, что он готов сам заниматься сборкой этого продукта, т.е. превращением из исходного кода в бинарный, и адаптацией его под конкретные условия, под дисциплину сборки программных продуктов, принятую в нашем дистрибутиве. Более того. в действительности дистрибутив — это конечный продукт некоей технологии, которая в качестве базового элемента имеет не дистрибутив, а то что называется хранилищем (англ. repository).

Хранилище

С точки зрения человека, не знакомого с этой технологией, хранилище выглядит просто как свалка, набор программных продуктов, адаптированных для работы в конкретном дистрибутиве. Набор достаточно внушительный, в хранилище ALTLinux их порядка 9 тысяч. Если приглядеться, в хранилище есть несколько дополнительных свойств, которые делают его не просто FTP-сайтом со складом файлов. Во-первых, файлы, которые помещаются в хранилище, помещаются туда мейнтейнерами пакетов.

Мейнтейнеры

Человек, который вдруг решил, что ему необходимо использовать некий программный продукт, который до этого не был адаптирован к некоторому дистрибутиву, может этот продукт скачать с сайта производителя, собрать из исходников бинарный пакет, и поместить результат работы в хранилище, пользуясь правами члена сообщества. Не всякий человек может туда положить пакет, а только тот, который, условно говоря, сдал экзамен на право называться разработчиком. Ничего такого в этом экзамене нет, человек просто должен показать, что он может в принципе такие вещи делать. Вот, допустим, в Debian GNU/Linux правила приёма сложнее, человек иногда не может годами туда попасть. Дело в том, что Debian --- это сообщество, которое полностью базируется на дисциплине. Там нет оплачиваемых людей, зарплату получают только администраторы сборочных серверов, больше никто, поэтому такие вещи там очень важны, если какой-то член core team против включения кого-то в состав разработчиков, значит есть тому резон.

Дисциплина оформления пакетов

В хранилище мейнтейнеры помещают исходный и собранный варианты программного продукта, адаптированного к местной дисциплине сборки. Пакет попадает в хранилище не сразу. Первым делом происходит проверка его на пригодность, на то, насколько правильно в нем соблюдена дисциплина сборки программных продуктов для хранилища (в случае Альт Линукс -- пакет помещается в хранилище под названием Сизиф, и проверка называется sisyphus-check). Дисциплина оформления пакетов в Сизиф -- это подробное описание, достаточно строгие рекомендации, что можно делать, а что нельзя, и фактически мейнтейнер закачивает в это хранилище не бинарный пакет, который он собрал руками, а адаптированный пакет с исходными текстами (исходный пакет), и специальный робот берет этот пакет, и собирает его по тем правилам, которые внутри пакета заключены. Если по этим правилам пакет собирается, значит, он соответствует дисциплине сборки пакетов. Если он не собирается, т.е. автоматом в изолированном окружении исходные тексты не удаётся превратить в бинарный продукт, значит мейнтейнер у себя использовал не такое окружение или забыл что-то ещё, и такой пакет в хранилище не помещается.

То есть

• проверяется формальное соответствие правилам оформления программных продуктов для Сизифа;
• фактическая его собираемость в изолированном окружении.

Было бы неплохо, если бы где-то были какие-то правила по тестированию, чтобы вместе с программным продуктов подготавливался некий набор тестов, на которых бы он запускался и работал, но такого не происходит, просто потому что это не всегда легко организовать. Если кто работал в промышленном программировании, он знает, что система тестирования занимает процентов 50 от общего времени разработки, и если авторы этого не сделали, то это очень сложно. Допустим, автор три года разрабатывал программный продукт, значит, чтобы написать полную систему тестов, нужно ещё три года.

Далее, предполагается, что если мейнтейнер поместил пакет в хранилище, то он

• сам им пользуется;
• тот факт, что он им пользуется и не видит никаких ошибок, как раз и есть если не лучший, то весьма эффективный способ тестирования. В конце концов, мало ли какие роботы какие программы как тестируют, а тут человек с помощью программы что-то делает, работает, она у него работает, и он на этом основании помещает её в хранилище.

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

Тут стоит заметить, что процедура сборки — превращения исходного текста в бинарный, результирующий программный продукт в изолированном окружении, в нашем хранилище Сизиф из известных во всем мире наиболее продвинутая и технологичная. В Debian все устроено примерно так же, но есть некие тонкие различия. Что касается других дистрибутивов, то там пожиже. Это достаточно непростой процесс, могу отослать к статьям Димы Левина про технологию сборки Сизиф и про hasher — инструмент, который позволяет организовывать изолированное окружение и сборку.

ftp://ftp.altlinux.org/pub/people/ldv/hasher/index.html

http://freesource.info/wiki/AltLinux/Dokumentacija/Hasher?v=vsm&search=hasher

Зависимости между пакетами. Обновления и стабильность

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

Хранилище Сизиф именно в связи с этим небезопасно для повседневного использования. Допустим, сопровождающий пакета, gtk (популярная интерфейсная библиотека графической среды, используемая многими программными продуктами), принимает решение, что новая версия gtk, со всякими изменениями внутри, очень хороша, и кладет ее в хранилище. Что при этом происходит? Все программные продукты, которые требуют библиотеку gtk, становятся нерабочими. Потому что библиотека новая, программы старые, собраны с предыдущей версией библиотеки, которой уже нет, вместо неё есть новая версия, а старая удалилась. Попытка воспользоваться этим множеством пакетов при таком состоянии хранилища, приведет к тому, что библиотека эта обновится, а все другие пакеты, от неё зависящие, удалятся на вашей машине, потому что у них есть неудовлетворённая зависимость. Это немедленно заметит сообщество, особенно те люди, которые используют Сизиф в качестве повседневного программного окружения, и за мейнтейнером gtk потянутся мейнтейнеры других программных продуктов, которые используют gtk, пересобирать свои программные продукты с поддержкой новой версии gtk. В какой-то момент ситуация вокруг gtk стабилизируется, потому что те мейнтейнеры, которым это интересно, поднимут свои версии, а те, которым это неинтересно и которых мы давно не встречали на просторах интернета, про это дело забудут, а программы останутся неработоспособными. Но если мейнтейнера у программы нет, практически это значит, что её никто не использует. Сизиф — это такое вечно нестабильно хранилище всего, и название как нельзя лучше отражает суть работы: вот ты значит старался-старался, компилировал-компилировал, исправлял причудливую мысль автора этой программы, наконец, все ошибки исправил, выложил в Сизиф, получил обратную связь от пользователей, ещё раз какие-то ошибки исправил, а через два дня вышла новая версия этой программы. Значит, камень скатывается обратно и все начинается сначала.

Заморозка. Стабильные ветки

Для того, чтобы этот процесс как-то упорядочить, некое подмножество значимых программных продуктов в этом самом хранилище регулярно, скажем, два раза в год (так принято в Сизифе) подвергается процедуре под названием заморозка. Замораживается весь Сизиф со словами: вот сейчас, в течение месяца-двух происходит заморозка, в течение которой никакие обновления версий этих программных продуктов недопустимы, кроме случаев, если программа обновляется вместе с устранением критических ошибок. Единственное, что разрешается делать, это устранять критические и вообще любые ошибки в ваших программных продуктах, если такие устранения появились, заниматься только этим, не смотреть в сторону новых версий, а смотреть на имеющиеся, из них удалять ошибки. В какой-то момент сообществу это дело надоедает, т.к. сообщество хочет все время новое все, и снимок достаточно стабильного состояния Сизифа, когда ситуация с новой библиотекой, которая все завалила — исправлена, откладывается в сторону под названием ветка (branch), после чего в этой ветке некоторое время по инициативе дистростроителей, то есть людей, которые будут делать дистрибутив, ещё продолжаются какие-то изменения, но по инерции. А сообщество работает дальше над Сизифом, который размораживается, через неделю приходит в абсолютно нерабочее состояние, потому что все туда накидают обновлений и экспериментируют вовсю, а что касается ветки, то в идеале её стабильность может только увеличиваться с течением времени, потому что туда будут помещать исправления ошибок, если кто-то в этом заинтересован.

Дистрибутивы

Кто заинтересован в том, чтобы исправлять ошибки в наборе ПО, который уже не развивается, потому что это ветка? Заинтересованы производители дистрибутивов, т.е. продуктов, которые распространяются и за распространение которых фирма хочет получить какие-то бонусы, начиная с продажи коробок, заканчивая внедрением в российские школы. Дистрибутивы делаются не на базе Сизифа. Берется ветка, в которой все уже более или менее устаканено, нет никаких строгих противоречий между программными продуктами, берется некое подмножество, поскольку дистрибутив отличается от хранилища тем, что в него входят только нужные программные продукты, и называется дистрибутивом.

Есть некоторая доля содержимого, входящего в дистрибутив, но не в хранилище -- это картинки, специальные версии программных продуктов, в которых что-то перенастроено, инсталлятор (хотя у нас он весь в Сизифе лежит, как в Debian, а у других дистрибутивов инсталлятор, как правило, пишется самостоятельно). Есть какая-то часть этих программных продуктов, которые даже ветке не принадлежат, но остальная часть берется из ветки. Дистростроитель понимает, что от исправления ошибок зависят потребительские свойства дистрибутива, и в ветку продолжают вносить какие-то изменения. Вот, собственно, технологический цикл: Постоянно нестабильное хранилище Сизиф, в которые постоянно помещают самые свежие версии программ, два раза в год осуществляется процесс заморозки, который приводит хранилище в относительно стабильное состояние, потом Сизиф отпускается, а сфотографированный стабильный срез продолжает жить своей жизнью, и его жизнь имеет две цели

• организация дистрибутивов на его основе
• ресурс для тех людей, которые взяли готовый дистрибутив, но которым потребовалось что-то ещё из стабильной ветки хранилища.

backports

Есть еще одно ответвление в этом технологическом процессе. Пусть есть хранилище, которое объявлено стабильным — ветка. В нем запрещается делать обновления, за исключением обновлений по безопасности и исправлений грубых ошибок. Что если мы хотим, пользуясь программным окружением этого стабильного хранилища, воспользоваться суперновой программой, которой либо вообще во времена стабилизации ветки в ней не было, либо со времён стабилизации она серьёзно обновилась? Болезнь новых версий у всех есть, даже у тех осторожных людей, которые не пользуются Сизифом, а пользуются дистрибутивами. Для них есть отдельное небольшое хранилище, которые поддерживается таким же сообществом больных новыми версиями, которое называется backports. Берутся пакеты из Сизифа и пересобираются в окружении ветки. Предполагается, что такого рода пересборка проходит (а бывает, что нет, допустим нужна более свежая версия компилятора), предполагается что использование пакетов из backports не портит стабильности ветки, хотя это никто не гарантирует. В любом случае, это намного лучше, чем пытаться одновременно брать пакеты со стабильной ветки и из Сизифа.

Относительно объёмов — хранилище содержит около 9000 пакетов. Типичный дистрибутив на DVD — порядка 4000 пакетов, на CD — порядка 800. Двухслойный DVD — 8000-9000 пакетов.

Посмотрим репозиторий

lftp ftp.altlinux.org

lftp ftp.altlinux.org:/pub> ls
lrwxrwxrwx    1 ftp      ftp            30 Jun 15  2007 Mozilla -> distributions/ALTLinux/Mozilla
lrwxrwxrwx    1 ftp      ftp            33 Jun 15  2007 OpenOffice -> distributions/ALTLinux/OpenOffice
drwxr-sr-x   10 ftp      ftp          4096 Jul 24 12:49 beta
drwxr-xr-x    6 ftp      ftp          4096 Aug 01  2006 distributions
drwxr-xr-x    5 ftp      ftp          4096 Apr 02  2006 docs
drwxrwsr-t    3 ftp      ftp          4096 Jun 10  2006 mirrors
drwxr-sr-x    5 ftp      ftp          4096 Mar 11  2003 partners
drwxr-xr-x   72 ftp      ftp          4096 Jul 09 14:51 people
drwxr-xr-x    3 ftp      ftp          4096 Jun 25  2004 security

Это все разные каталоги, тут нет строгой дисциплины, за исключением желаний отдельных людей или групп что-то поместить.

lftp ftp.altlinux.org:/pub/distributions> ls
drwxr-xr-x   13 ftp      ftp          4096 Jul 30 21:49 ALTLinux
drwxr-xr-x    3 ftp      ftp          4096 Feb 21  2006 FreeMusic
drwxr-xr-x    3 ftp      ftp          4096 Feb 21  2006 OpenMusic
drwxr-xr-x    3 ftp      ftp          4096 Jun 15  2007 archive

Это по именам дистрибутивов.

lftp ftp.altlinux.org:/pub/distributions/ALTLinux> ls
drwxr-xr-x    3 ftp      ftp          4096 Feb 13  2003 2.2
drwxr-xr-x    4 ftp      ftp          4096 Jul 01  2004 2.3
drwxr-xr-x    3 ftp      ftp          4096 Nov 03  2004 2.4
drwxr-xr-x   10 ftp      ftp          4096 Mar 03  2006 3.0
drwxr-xr-x    7 ftp      ftp          4096 Jun 05 20:14 4.0
drwxr-xr-x    3 ftp      ftp          4096 May 07 00:12 4.1
drwxrwsr-x    4 ftp      ftp          4096 May 31  2007 Daedalus
drwxr-xr-x   14 ftp      ftp          4096 Aug 01 07:09 Sisyphus
drwxrwsr-x    8 ftp      ftp          4096 May 12 09:57 backports
drwxr-xr-x    5 ftp      ftp          4096 Jul 30 21:37 old
drwxr-xr-x    9 ftp      ftp          4096 Dec 09  2007 updates

• Sisyphus — это хранилище Сизиф,

• 2.2, 2.3, ..., 4.1 — это стабильные ветки, сделанные в своё время.

• backports — это backports (внутри — по веткам)

• updates — обновления к веткам и дистрибутивам (по отдельности, т.к. одно и то же может обновляться по-разному из-за особенностей допилки в дистрибутивах)

Рассмотрим свойства пакетов. Обратимся сначала к истории их появления. Итак, в подавляющем большинстве случаев Вы скачиваете пакет не с сайта продукта, а берёте из хранилища, которое поддерживается сообществом. В хранилище пакет появился благодаря ментейнеру, который скачал исходные тексты, оформил их в соответствии с дисциплиной сборки программных продуктов в хранилище, собрал, т.е. получил бинарный продукт. В результате в хранилище появились: пакет с исходным кодом, 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 в чем-то совпадает, вам ничего не дадут сделать, даже если конфликта по файлам нет. Таким образом, конфликт может быть не только результатом недосмотра двух мейнтейнеров, но и сознательно введенным механизмом, предотвращающим ошибочные действия.

Установщик

Для того, чтобы пакет установить, удалить или просмотреть о нем информацию, используется специальная программа --- установщик пакетов. Заметим, что эта же программа по традиции отвечает за сборку пакета из исходных текстов по заранее составленной "инструкции" --- так называемому spec-файлу. В подавляющем большинстве случаев установщик пакетов работает ровно с одним пакетом: этот пакет может быть как установлен в системе, так и нет. Установщик пакетов в ПСПО ALT Linux называется RPM (RPM Package Manager, ранее Red Hat Package Manager, то есть установщик пакетов в дистрибутивах Red Hat Linux).

Возьмем уже скачанный нами пакет zip-2.32-alt2.S40.1.i586.rpm и воспользуемся утилитой rpm для просмотра списка файлов в этом пакете (ранее мы уже проделывали такую операцию "вручную" --- с помощью программы rpm2cpio):

$ rpm -qpl zip-2.32-alt2.S40.1.i586.rpm
/usr/bin/zip
/usr/bin/zipcloak
/usr/bin/zipnote
/usr/bin/zipsplit
/usr/share/doc/zip-2.32
/usr/share/doc/zip-2.32/BUGS
/usr/share/doc/zip-2.32/CHANGES
/usr/share/doc/zip-2.32/LICENSE
/usr/share/doc/zip-2.32/MANUAL
/usr/share/doc/zip-2.32/README
/usr/share/doc/zip-2.32/TODO
/usr/share/doc/zip-2.32/WHATSNEW
/usr/share/doc/zip-2.32/WHERE
/usr/share/man/man1/zip.1.bz2

Ключ -q задает один из основных режимов работы утилиты rpm и означает "выполнить запрос" (query). Ключ -p (package) заставляет утилиту работать не с установленным в системе пакетом, а с пакетом, лежащим в указанном файле (это один из способов указать на нужный пакет), а ключ -l (file list) задает нужное нам действие: показать список файлов. (Заметим, что запрос можно было осуществить и с помощью команды rpmquery -pl zip-2.32-alt2.S40.1.i586.rpm.) Если же требуется вывести список файлов, относящихся к уже установленному пакету, ключ -p использовать не следует. В этом случае выбор пакета будет осуществляться по его имени (достаточно использовать краткую форму --- zip).

Выполним еще несколько запросов с помощью rpm. Просмотрим информацию (ключ -i --- info) об установленном в системе пакете tar (tape archiver):

[george@demo ~]$ rpm -qi tar
Name        : tar                          Relocations: (not relocateable)
Version     : 1.15.1                            Vendor: ALT Linux Team
Release     : alt8                          Build Date: Сбт 14 Апр 2007 20:01:52
Install date: Втр 15 Июл 2008 21:23:38      Build Host: ldv.hasher.altlinux.org
Group       : Архивирование/Резервное копирование   Source RPM: tar-1.15.1-alt8.src.rpm
Size        : 1213918                          License: GPL
Packager    : Dmitry V. Levin <ldv@altlinux.org>
URL         : http://www.gnu.org/software/tar/
Summary     : Утилита проекта GNU для архивации файлов
Description :
The GNU tar program saves many files together into one archive and
can restore individual files (or all of the files) from the archive.
tar can also be used to add supplemental files to an archive and to
update or list files in the archive.  tar includes multivolume support,
automatic archive compression/decompression, the ability to perform
remote archives and the ability to perform incremental and full backups.

Посмотрим теперь историю изменений (changelog) в сборке tar:

[george@demo ~]$ rpm -q --changelog tar
* Сбт Апр 14 2007 Dmitry V. Levin <ldv@altlinux.org> 1.15.1-alt8

- Reduced macro abuse in specfile.

* Втр Ноя 28 2006 Dmitry V. Levin <ldv@altlinux.org> 1.15.1-alt7

- Disabled GNUTYPE_NAMES handling by default and
  added --allow-name-mangling option to re-enable it.
  (CVE-2006-6097, patch from Kees Cook).
 ...

Отметим еще раз, что запросы можно осуществлять как с помощью rpm -q, так и с помощью rpmquery.

Займемся теперь установкой пакетов из файлов. Скачаем несколько архивов из хранилища и используем утилиту rpm с ключом -i (install). Заметим, что в данном случае ключ -i задает основной режим работы rpm и имеет отличное от рассмотренного выше значения. Естественно, для установки пакетов требуются права суперпользователя.

[root@demo ~]# rpm -i xvfb-run-1.2-alt2.noarch.rpm
error: failed dependencies:
        xorg-x11-xvfb is needed by xvfb-run-1.2-alt2
        fakeroot is needed by xvfb-run-1.2-alt2

Как видно, установщик отказывается устанавливать пакет: для установки xvfb-run-1.2-alt2 оказались нужны отсутствующие в системе xorg-x11-xvfb и fakeroot. Возьмем теперь пакет без неудовлетворенных зависимостей:

[root@demo ~]# rpm -i vim-plugin-moin-syntax-1.8-alt2.noarch.rpm

Утилита rpm молча завершает работу, что свидетельствует об успешном выполнении запрошенной операции. Какие же файлы появились в нашей системе?

[root@demo ~]# rpm -ql vim-plugin-moin-syntax
/etc/alternatives/packages.d/moinmoin.vim
/usr/share/vim/ftplugin/moin.vim
/usr/share/vim/syntax/moinmoin.vim

Как видно, их всего три. Давайте теперь вернемся к неустановившемуся пакету xvfb-run-1.2-alt2. Его установка привела бы к появлению в системе лишь одного нового файла:

[root@demo ~]# rpm -qpl xvfb-run-1.2-alt2.noarch.rpm
/usr/bin/xvfb-run

Посмотрим, наличия чего требует (requires) для установки этот пакет:

[root@demo ~]# rpm -qpR xvfb-run-1.2-alt2.noarch.rpm
xorg-x11-xauth
xorg-x11-xvfb
fakeroot
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
coreutils
sh

Утилита rpm с ключом -R выдает список зависимостей пакета. В нашем случае неудовлетворенными остались, как мы помним, две (а для того, чтобы rpm отказалась устанавливать пакет, достаточно было и одной).

Попробуем теперь выполнить удаление (ключ -e, erase) пакета vim-plugin-moin-syntax: его мы установили только что, поэтому никакой другой из имеющихся в системе пакетов от него не зависит.

[root@demo ~]# rpm -e vim-plugin-moin-syntax

Как мы видим, удаление прошло успешно. Если же попробовать удалить пакет, от которого зависят другие установленные пакеты, то rpm откажется это делать:

[root@demo ~]# rpm -e coreutils
error: removing these packages would break dependencies:
        coreutils   is needed by dmsetup-1.02.22-alt1
        coreutils   is needed by less-394-alt1
        coreutils   is needed by module-init-tools-compat-3.3-alt0.5.pre6
        ...

Диспетчер

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

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

В ПСПО ALT Linux традиционно используется портированный из дистрибутивов Debian GNU/Linux диспетчер APT (Advanced Package Tool), изначально ориентированный на использование установщика dpkg и формата пакетов deb. APT предоставляет целый комплект утилит для работы с хранилищами. Мы рассмотрим две из них:

• утилиту apt-get, работающую с хранилищами непосредственно;
• утилиту apt-cache, работающую с индексами --- информацией о том, что находится в хранилище.

Смысл разделения на apt-get и apt-cache состоит в следующем: apt-get при своей работе обыкновенно использует сеть, скачивая информацию о пакетах и формируя индексы, apt-cache же сети для своей работы не требует, используя информацию из локальных копий индексов. Какие именно хранилища используются утилитой apt-get, указано в специальном месте. Речь об этом пойдет далее, а мы сейчас установим-таки xvfb-run, воспользовавшись возможностями APT:

[root@demo ~]# apt-get install xvfb-run
Reading Package Lists... Done
Building Dependency Tree... Done
The following extra packages will be installed:
  fakeroot xorg-x11-xvfb
  The following NEW packages will be installed:
    fakeroot xorg-x11-xvfb xvfb-run
    0 upgraded, 3 newly installed, 0 removed and 0 not upgraded.
    Need to get 1708kB of archives.
    After unpacking 4341kB of additional disk space will be used.
    Do you want to continue? [Y/n]
    Get:1 ftp://ftp.altlinux.org i586/classic fakeroot 1.9.4-alt2 [48.5kB]
    Get:2 ftp://ftp.altlinux.org i586/classic xorg-x11-xvfb 2:1.3.0.0-alt21.M40.10 [1656kB]
    Get:3 ftp://ftp.altlinux.org noarch/classic xvfb-run 1.2-alt2 [4107B]
    Fetched 1708kB in 0s (3963kB/s)
    Committing changes...
    Preparing...                 ####################################################### [100%]
    1: fakeroot                  ####################################################### [ 33%]
    2: xorg-x11-xvfb             ####################################################### [ 66%]
    3: xvfb-run                  ####################################################### [100%]
    Done.

Как видно, мы использовали команду apt-get с параметром install. В нашем случае она выполнила следующие операции:

1. Просмотрела все индексы.
2. Построила дерево зависимостей.
3. Нашла пакет --- кандидат на установку (заметим, что мы могли потребовать установить сразу несколько пакетов).
4. Предупредила, что помимо этого (для удовлетворения зависимостей) надо установить еще два пакета.
5. Запросила подтверждение на установку дополнительных пакетов.
6. Скачала все необходимые пакеты из хранилища.
7. Установила их в правильном порядке.

Отметим, что команду apt-get install можно использовать и для обновления уже установленного пакета до версии из хранилища. Для обновления же всей системы целиком используется команда apt-get dist-upgrade (непосредственно перед этим действием рекомендуется дать команду apt-get update для обновления индексов --- но об этом чуть позже).

Заметим, что с рекурсивной установкой и рекурсивным удалением есть свои проблемы. Предположим, мы установили пакет, который рекурсивно потянул за собой много дополнительных пакетов. Через некоторое время после этого мы решаем все установленные таким образом пакеты удалить. Как это сделать? Увы, в общем случае ответ --- никак. Дело в том, что при рекурсивном удалении удалятся лишь те пакеты, которые зависят от выбранного (те, которые не могут существовать без него). Пакеты же, от которых зависел выбранный пакет, удалены не будут. В результате в системе останется довольно много пакетов, которые на самом деле никому не нужны.

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

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

Рассмотрим теперь, как происходит рекурсивное удаление. Попробуем избавиться от пакета fakeroot, от которого зависит установленный нами xvfb-run. Для этого нам понадобится параметр remove утилиты apt-get:

root@demo ~]# apt-get remove fakeroot
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages will be REMOVED:
  fakeroot xvfb-run
0 upgraded, 0 newly installed, 2 removed and 0 not upgraded.
Need to get 0B of archives.
After unpacking 77.9kB disk space will be freed.
Do you want to continue? [Y/n] n
Abort.

Здесь, увидев, что xvfb-run тоже придется удалить, мы одумались и отменили запрошенные действия. Попробуем теперь удалить пакет coreutils --- это пакет, который жизненно необходим системе:

[root@demo ~]# apt-get remove coreutils
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages will be REMOVED:
 GConf ImageMagick SysVinit Thunar a2ps abiword acpid alsa-utils alt-docs-genextras
 alt-docs-main alterator alterator-aptgroups alterator-auth alterator-backend-x11
 alterator-browser-qt alterator-control alterator-datetime alterator-lookout
 ...
WARNING: The following essential packages will be removed
This should NOT be done unless you know exactly what you are doing!
 apt rpm (due to apt) gnupg (due to apt) basesystem coreutils (due to basesystem) etcskel
 (due to basesystem) service (due to basesystem) shadow-utils (due to basesystem) startup
 (due to basesystem) SysVinit (due to basesystem) util-linux (due to basesystem) vitmp
 (due to basesystem)
0 upgraded, 0 newly installed, 562 removed and 0 not upgraded.
Need to get 0B of archives.
After unpacking 1494MB disk space will be freed.
You are about to do something potentially harmful
To continue type in the phrase 'Yes, do as I say!'

Диспетчер предупреждает, что некоторые из пакетов, которые придется удалить, помечены как essential (жизненно важные для системы) и просит для подтверждения набрать не просто y (yes --- да), а целую фразу "Yes, do as I say!" ("Да, сделай так, как я говорю!"). Естественно, подтверждать удаление надо только в случае абсолютной уверенности в своих действиях. Откажемся теперь от удаления coreutils.

Рассмотрим еще некоторые возможности диспетчера. Для поиска пакетов используется утилита apt-cache с параметром search:

[root@demo ~]# apt-cache search kde
amarok - Amarok is a music player for KDE.
arts - aRts (analog realtime synthesizer) - the KDE sound system
desktop-file-utils - Utilities for manipulating .desktop files
digikam - A Photo Management Application for KDE
docs-linux_gui - Graphical user interface in Linux
gambas-gb-qt-kde - The Gambas KDE component
gambas-gb-qt-kde-html - The Gambas KHTML component
kaffeine - A Xine-based Media Player for KDE
kchmviewer - KchmViewer is a chm (MS HTML help file format) viewer
kde-common - The basic directory layout for KDE
kde-common-devel - Development utils for KDE
...

Заметим, что apt-cache search ищет ключевое слово не только в коротком, но и в длинном описании пакета. Естественно, при поиске используются не сами хранилища, а локальные индексы (за поиск отвечает apt-cache, а не apt-get). Чтобы просмотреть информацию о лежащем в хранилище пакете, можно воспользоваться параметром show:

[root@demo ~]# apt-cache show xword
Package: xword
Section: Text tools
Installed Size: 63480
Maintainer: Vitaly Lipatov <lav@altlinux.ru>
Version: 1.0-alt1
Pre-Depends: rpmlib(PayloadFilesHavePrefix) (<= 4.0-1), rpmlib(CompressedFileNames) (<= 3.0.4-1)
Depends: python-module-pygtk, coreutils
Provides: gedam, xword (= 1.0-alt1)
Obsoletes: gedam
Architecture: noarch
Size: 21742
MD5Sum: 5d9baebcbbb103782b3918d7c555742c
Filename: xword-1.0-alt1.noarch.rpm
Description: Xword is a GNOME crossword puzzle program
Gedam is a GNOME program I wrote for doing crossword puzzles. It is
similar to the AcrossLite program for Windows, and it can read and write
the file format of that program. Consequently, it works well for doing
puzzles from The New York Times. Although there is an existing version
of AcrossLite for Linux, it has several glaring problems: poor support,
the use of Motif, and the lack of a clock.

For crossword files search in Google by "AcrossLite", f.i.
http://puzzles.about.com/library/weekly/aa040697.htm

Скажем теперь несколько слов об индексах. Для их обновления используется команда apt-get с параметром update. Она скачивает с используемых хранилищ все индексы и заново формирует локальный кэш:

[root@demo ~]# apt-get update
Get:1 ftp://updates.altlinux.org i586 release [720B]
Get:2 ftp://ftp.altlinux.org i586 release [1005B]
Get:3 ftp://ftp.altlinux.org i586 release [730B]
Get:4 ftp://ftp.altlinux.org noarch release [728B]
Get:5 ftp://ftp.altlinux.org i586 release [702B]
Fetched 3885B in 0s (7192B/s)
Hit ftp://updates.altlinux.org i586/updates pkglist
Hit ftp://ftp.altlinux.org i586/classic pkglist
Hit ftp://updates.altlinux.org i586/updates release
Hit ftp://ftp.altlinux.org i586/classic release
Hit ftp://ftp.altlinux.org i586/classic pkglist
Hit ftp://ftp.altlinux.org i586/classic release
Hit ftp://ftp.altlinux.org noarch/classic pkglist
Hit ftp://ftp.altlinux.org noarch/classic release
Hit ftp://ftp.altlinux.org i586/backports pkglist
Hit ftp://ftp.altlinux.org i586/backports release
Reading Package Lists... Done
Building Dependency Tree... Done

Какие именно хранилища используются при работе утилитами семейства APT, указано в конфигурационных файлах каталога /etc/apt. В файле apt.conf содержатся общие настройки системы APT, а за используемые хранилища отвечает файл sources.list (он вполне может быть пустым) вместе со всеми файлами каталога sources.list.d. В этом каталоге может лежать значительное количество файлов, содержащих информацию о различных хранилищах пакетов в разнообразных местах. Типичная строка в файле из этого каталога выглядит примерно так:

# rpm [updates] ftp://ftp.altlinux.org/pub/distributions/ALTLinux/4.0/branch noarch classic

Символ решетки в начале строки является маркировкой комментария --- иными словами, соответствующая запись в данный момент не используется вовсе. Формат записи таков: вначале --- тип пакета (rpm), затем --- идентификатор цифровой подписи в прямых скобках (иногда пропускается), далее --- URL хранилища, название хранилища, одно или несколько названий веток.

Отметим, что наличие большого количества файлов в /etc/apt/sources.list.d объясняется существованием большого числа зеркал различных хранилищ. Использование того или иного зеркала может оказаться более или менее удобным по сетевым соображениям. Чтобы воспользоваться хранилищем, необходимо раскомментировать соответствующие строки (их может быть несколько) в нужном файле, удостовериться, что ненужных раскомментированных строк нет (учитываются все файлы в sources.list.d и, кроме них, файл sources.list), и дать команду apt-get update для обновления локальных индексов. Обновлять индексы следует также непосредственно перед выполнением apt-get dist-upgrade, чтобы при обновлении системы использовались актуальные их версии.

Диспетчер пакетов

В разделе "Система" главного меню выберем "Диспетчер пакетов". Для установки и удаления программ, так же как для управления системой и настройки сети, необходимы права суперпользователя. Программа Synaptic (Диспетчер пакетов) --- это по сути не более чем графический интерфейс к семейству утилит apt. Однако, в некоторых случаях использование Synaptic может оказаться предпочтительней, чем работа с apt в командой строке. Перечислим основные преимущества графического диспетчера задач.

• Наличие каталогизатора.
• Возможность легко и быстро получить информацию о пакете (просто выделив его).

  

• Возможность ускорить и облегчить установку большого количества программных продуктов. Вы можете пометить (двойным щелчком левой кнопкой мыши) сразу несколько пакетов для установки, и затем установить их одним нажатием кнопки "Применить". Обратите внимание, что просто пометить пакеты недостаточно.

Другие варианты установки программ

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

• Архивы. Наиболее предпочтительный для использования вид бинарных сборок. Как правило, для корректной работы достаточно распаковать такой архив. Обычно его распаковывают в каталог /opt.
• rpm. Весьма часто программы распространяются в виде rpm-пакетов. Однако, в этом случае при установке могут возникнуть трудности. Существуют некоторые различия в именах пакетов в ALTLinux и других дистрибутивах, использующих rpm, в следствие чего, при установке rpm могут появиться зависимости, удовлетворить которые возможно лишь восстановив соответствие между именами в ALTLinux и rpm-based дистрибутивах. В общем случае это нетривиальная задача.
• Бинарные установщики. Наименее удобным вариантом бинарной сборки является самостоятельная программа-установщик. С одной стороны, при использовании этого варианта, пользователю не задается вопросов о зависимостях. Но, с другой стороны, весьма сложно отследить, что именно делает подобный установщик. Успешный результат в этом случае отнюдь не гарантирован. В отличие от rpm, не гарантировано и восстановление исходного состояния системы при возникновении проблем. Отчасти, проблему использования таких установщиков можно решить, проводя установку в изолированном окружении.

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

Несмотря на то, что:

• хранилища содержат очень много различного программного обеспечения;
• пакеты ставить в любом случае проще и комфортнее для пользователя, чем какие-либо приложения с собственным инсталлятором;

иногда всё-таки возникает необходимость воспользоваться каким-то приложением, которое распространяется исключительно под Windows.

Для того, чтобы осуществить подобное, в Linux используется программа WINE (WINE = Wine Is Not an Emulator).

Таким образом, название сообщает нам, что эта программа не является эмулятором. И верно, на деле принцип работы Wine проще: так как windows-приложение состоит из тех же процессорных инструкций, что и любое другое приложение под данный процессор, то для его исполнения достаточно сделать вид, что оно исполняется в привычной для себя Windows-среде --- т.е. вызывает из нужных библиотек нужные функции, распознает правильную абстракцию файловой системы и т.д.

Параметры данной "искуственной" среды задаются в конфигурационных файлах wine (их удобно редактировать с помощью утилиты winecfg): к примеру, там задаётся соответствие "дисков" Windows, которые сможет "увидеть" запускаемая Windows-программа, некоторым каталогам вашей файловой системы в Linux. Стоит быть осторожным при задании этих каталогов: если исполняемое при помощи wine приложение находится вне них, работать оно не будет.

Могут возникнуть и другие неожиданности --- например, при запуске консольных Windows-приложений:

[user@demo ~]$ wine Far.exe
err:winedevice:ServiceMain driver L"eusk3usb" failed to load
err:winedevice:ServiceMain driver L"SNTNLUSB" failed to load
err:seh:setup_exception_record stack overflow 188 bytes in thread 0009 eip cdcdcdcd esp 00231274 stack 0x230000-0x231000-0x330000

Far Commander не запустится просто так, потому что здесь он должен работать в консоли Linux. Wine сам этого отличить не может, и надо это явно указать: wine-console --backend=user Far.exe

Также при работе с консольными приложениями, скорее всего, стоит указать в конфигураторе winecfg режим эмуляции Windows 98 из-за некоторых проблем с вызовом программ в консоли Windows.

Но, увы, все эти и многие другие ухищрения могут ни к чему не привести - большое количество Windows-приложений ни при каких условиях не сможет заработать в среде wine по тем или иным причинам. Сообщество поддерживает различные базы приложений, работающих в wine, одна из них находится на самом сайте wine --- Wine HQ App DB.

Чтобы завершить наш разговор на тему пакета wine, определим его общее предназначение: wine --- свободная программа, предназначенная для запуска Windows-программ. Помимо этого, на базе wine в данный момент разрабатываются как минимум три известных несвободных версии, которые предназначены для более специфичных прикладных задач:

• Cedega --- расширенный wine с встроенной поддержкой DirectX для запуска Windows-игр. Разработкой и поддержкой программы занимается компания Transgaming software;
• Crossover office --- расширение wine, созданное для запуска и комфортной работы с офисными Windows-приложениями;
• В Санкт-Петербурге функционирует команда wine@etersoft, которая занимается приспособлением wine для запуска программных продуктов, специфичных для российского рынка --- 1С, генераторы отчётов и документов и т.д. В отличие от предыдущих программных продуктов, wine@etersoft local --- свободный программный продукт, и в такой версии он входит в дистрибутив ALTLinux. Помимо версии local существуют также версии network и sql: первая позволяет запускать продукты 1С для многопользовательской работы с клиентами, а вторая умеет транслировать sql-запросы по образу и подобию Microsoft SQL. Кстати, документация для wine, созданная wine@etersoft, рекомендуется к прочтению как лучшая из существующих.

Стоит отметить, что приложения на Java, скорее всего, будут работать.