Debian и Ubuntu: пакеты и репозитории

Citkit, март 2006 - январь 2007

Пакеты и их зависимости

Формат пакетов (deb) дистрибутива Debian, как и основанные на нём средства пакетного менеджмента - в числе выдающихся достижений его разработчиков, унаследованное всеми Debian-клонами.

Пакет Debian - архивный файл (собранный утилитой ar), содержащий два обычных архива *.tar.gz, один из которых включает скомпилированные исполняемые бинарники (и необходимые им для работы компоненты - библиотеки, конфиги, документацию и так далее), второй же - так называемые управляющие файлы: контрольные суммы, описания зависимостей, пред- и постинсталляционные сценарии.

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

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

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

В Debian зависимости имеют несколько градаций: обязательные (depends), настоятельно рекомендуемые (recommends), рекомендуемые умеренно настойчиво (suggests), конфликтующие (conflicts). Первая градация - это обычные "жесткие" зависимости. С последними тоже понятно - это, так сказать, анти-зависимости. Ну а настоятельно рекомендуемые и рекомендуемые просто - это две разновидности "мягких" зависимостей. То есть первая категория как бы более нужная, нежели вторая. Впрочем, таково субъективное мнение майнтайнера данного пакета - вполне возможно, что у пользователя будут иные потребности. И это мы учтем при выборе средства управления пакетами.

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

Кроме зависимостей, в системах пакетного менеджмента Debian важно также понятие приоритета пакета. отражающее степень необходимости его для функционирования системы, например: обязательный (required), без которого функционирование системы невозможно, основной (base) и важный (important), также оказывающиеся практически необходимыми, стандартный ( - то есть имеющийся практически в любой полнофункциональной Linux-системе, дополнительный (optional) - тут уж степень важности каждый должен решать для себя.

Как это принято в мире Open Source, все бинарные пакеты Debian (а также, конечно, Ubuntu и других клонов) сопровождаются исходными текстами, доступными из репозиториев дистрибутива. И здесь Debian проявляет свою специфику: каждый пакет в исходниках обычно включает три файла - packagename.orig.tar.gz, packagename.dsc и packagename.diff.gz.

Первый - самый обычный тарбалл исходных текстов авторского пакета, что подчеркивается словом orig в его имени: имя и система нумерации версий также совпадают с таковыми авторского пакета. Файл packagename.dsc содержит в себе всю метаинформацию, необходимую для правильного построения из него бинарного deb-пакета (как - будет рассказано в следующих разделах). А packagename.diff.gz - это те изменения исходного кода, которые вносятся для адаптации пакета непосредственно к данному дистрибутиву. Если таких изменений не потребовалось (или если пакет писался именно для Debian), он может и отсутствовать.

Средства управления пакетами Debian: обзор

В отношении средств управления пакетами в Debian и его клонах имеется богатый выбор:

• команда dpkg, предназначенная для установки, конфигурирования и удаления единичных пакетов, но не имеющая собственных средств разрешения зависимостей между ними;
• dselect - front-end (оболочка) для dpkg, работающая в текстовом режиме; обеспечивает не только установку/удаление программ, но и групповой выбор пакетов по целевому назначению, а также разрешение зависимостей между ними;
• механизм apt - универсальный набор инструментов для управления deb-пакетами, включая разрешение зависимостей между ними и даже построение из исходников отдельных пакетов и тотальную пересборку установленной системы с заданными параметрами компиляции;
• aptitude - оболочка для apt, как по интерфейсу, так и функционально схожая с dselect;
• sinaptic - также оболочка для утилит семейства apt.

Все эти средства унаследованы от прародителя - Debian'а его клонами. Которые, однако, могут включать в себя и собственный инструментарий пакетного менеджмента. Так, в Kubuntu имеется собственный менеджер пакетов - Adept, предназначенный для работы в графической среде KDE. Это очень интересная программа (также, насколько я понимаю, front-end над apt), но ее еще нельзя считать достаточно отлаженной. Будем надеяться на совершенствование ее в грядущих версиях Kubuntu.

Устройство репозитория Ubuntu

Раздел написан в соавторстве с Владимиром Поповым

Дистрибутив Debian GNU/Linux давно и по праву славится своей системой управления пакетами. Успех которой слагается из трех компонентов:

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

Потомки Debian, такие, как MEPIS, Xandros, Linspire, вместе с форматом пакетов унаследовали от прародителя и все остальные составляющие удачливого пакетного менеджмента. B, конечно же, все они характерны и для самого популярного деривата Debian - семейства дистрибутивов Ubuntu, каковое и будет предметом дальнейшего рассмотрения.

Ниже будет рассмотрено устройство репозиториев Ubuntu, что преследует две цели. Первой является чисто удовлетворение собственного любопытства - дабы поглядеть, как оно устроено "внутре". Но есть и цель практическая: каким образом можно получать информацию о пакетах с машины, не имеющей подключения к Сети - согласитесь, в нашей умеренно интернетизированной СНГовии задача достаточно актуальная.

Сразу следует оговориться, что без физического доступа к Сети вообще использование средств пакетного менеджмента Debian может носить предельно ограниченный характер, распространяясь только на реопзитории с "твердых" носителей, типа дистрибутивных компактов. Нет, речь идет все-таки о случае, когда какой-никакой доступ к Сети все-таки имеется, только не с той машины и, возможно, не с той платформы, на которой Ubuntu используется (например, со служебной машины под управлением Windows).

Сначала - пара слов о репозиториях Ubuntu вообще. Официальные репозитории Ubuntu - общие для всех дистрибутивов семейства, и располагаются они по адресу: http://archive.ubuntu.com/ubuntu/. Это - "головное" хранилище пакетов, имеющее многочисленные региональные зеркала, принадлежность которых к стране указывается стандартным двухсимвольным префиксом, например:

* http://no.archive.ubuntu.com/ubuntu/ - норвежское зеркало,
* http://ru.archive.ubuntu.com/ubuntu/ - российское зеркало,

и так далее. Кроме официального репозитория, имеются также репозитории, так сказать, полуофициальные. Для пользователей Kubuntu, например, важнейшим из них будет http://kubuntu.org/packages/. Последние версии KDE, KOffice, Amarok в нем появляются существенно раньше, чем в официальном репозитории. Кроме того, только в нем можно найти тестовые версии указанных пакетов. В частности, в настоящее время это единственный репозиторий, из которого можно получить в бинарном виде тестовую версию KDE 4.

Чтобы получить представление о внутреннем устройстве репозитория Ubuntu, посетим одно из его зекрал, например, http://ru.archive.ubuntu.com/ubuntu/. Внутре него видим файл ls-lR.gz (представляющих собой полный список всего файлового дерева репозитория, с атрибутами принадлежности, доступа, и так далее), а также следующие каталоги:

dists/
indices/
pool/
project/

Назначение каталога project/ показалось мне не вполне понятным, каталог indices/ содержит нечто вроде списков файлов, в каталоге dists/ описываются всякого рода сведения о пакетах, а сами они имеют место быть в каталоге pool/. Собственно, два последних каталога нас и будут интересовать.

Начнем с описания пакетов, то есть содержимого каталога dists/. Надо сказать, что классификация пакетов в Ubuntu выглядит еще более запутанной, чем в Debian'е, где она тоже не являет собой эталон прозрачности.

В первом приближении пакеты классифицируются по именам релизов - на текущий момент актуальны релизы Dapper (6.06, точнее, ее bugfix-редакция 6.06.1), которому обещана пятилетняя поддержка, Edgy (6.10) - последний по времени стабильный релиз, и Feisty (будущий 7.04) - то, что станет релизом весной 2007 года (если полугодовой цикл разработки не будет нарушен). Но описания всех предыдущих релизов Ubuntu также имеются в каталоге dists/, образуя самостоятельные подкаталоги. В качестве исторической справки напомню, что это были Breezy (5.10) и Hoary (5.04). Лишь следов самой первой версии, Warty (4.10) не удается найти в репозитории.

Далее, в каждом релизе, помимо основного массива пакетов, выделяются еще и так называемые категории - каждой из них соответствует подкаталог того же уровня, что и подкаталог релиза, а именуются они так (на примере релиза edgy):

edgy-backports/
edgy-proposed/
edgy-security/
edgy-updates/

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

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

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

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

main/
restricted/
universe/
multiverse/

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

binary-amd64/
binary-i386/
binary-powerpc/
binary-sparc/

каталог писания пакетов исходников

source/

каталог с переводами описаний

i18n

Каждый каталог содержит три файла: Release - файл с общей информацией о ветке репозитория, Packages.gz и Packages.bz2, которые на самом деле представляют собой один и тот же файл Packages, сжатый утилитами gzip и bzip2, соответственно. Файл Release, как явствует из его названия, представляет собой общее описание компонента данного релиза, и выглядит примерно так:

Archive: edgy
Version: 6.10
Component: main
Origin: Ubuntu
Label: Ubuntu
Architecture: amd64

Содержание же файл Packages - полный список пакетов данного компонента и архитектуры. Для каждого пакета из этого списка приводятся:

• Package: название пакета (например, adduser);
• Priority: приоритет (required, important, optional и так далее);
• Section: принадлежность к целевой группе (base, admin, gnome, kde и т.д.);
• Installed-Size: объем, занимаемый пакетом и его составляющими в установленном виде (Кбайт);
• Maintainer: сборщик дистрибутивного пакета (например, Ubuntu Core Developers) и его e-mail;
• Original-Maintainer: разработчик авторского пакета и его e-mail;
• Architecture: целевая платформа (например, i386, amd64 или ppc);
• Version: номер версии оригинального пакета и сборки пакета дистрибутивного (примерно так - 2.4.6-1.1ubuntu1);
• Replaces: пакеты, заменяемые данным (если таковые имелись ранее);
• Depends: жесткие, то есть обязательные, зависимости, с указанием минимальной версии, например: debianutils (>= 1.6);
• Recommends: рекомендуемые, то есть мягкие, зависимости;
• Suggests: предлагаемые (еще более "мягкие") зависимости;
• Conflicts: пакеты, конфликтующие с данным;
• Filename: полный путь к deb-файлу пакета, отсчитываемый от каталога pool (см. далее);
• Size: размер файла deb-пакета (в байтах);
• MD5sum: контрольная md5-сумма;
• SHA1: идентификатор подлинности;
• SHA256: он же, 256-битный;
• Description: краткое описание пакета;
• Bugs: адрес для высылки сообщений об ошибках в программе;
• Origin: происхождение (Ubuntu);
• Task: категория, в составе которой пакет устанавливается (например, minimal, standard, ubuntu-desktop, kubuntu-desktop, и так далее).

То есть здесь мы видим нечто вроде аккумулятивной суммы файлов control для всех пакетов репозитория, с единственным добавлением строки Filename, описывающей путь к данному пакету именно в данном репозитории.

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

Классификация же собственно пакетов, с которой только и сталкивается пользователь (да и то не совсем вплотную), гораздо проще, в чем можно убедиться при рассмотрении подкаталога pool/ (то есть "пула" пакетов). Здесь мы видим всего четыре подкаталога, соответствующие указанным выше компонетам дистрибутива:

main/
restricted/
universe/
multiverse/

Компоненты группируются следующим образом:

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

Понимание свободно распространяемых программ с точки зрения лицензии Ubuntu примерно соответствует принципам свободного программного обеспечения Debian, которое, в свою очередь, весьма сходно с пониманием свободного софта FSF. Пакеты из компонентов restricted и multiverse имеют разного рода ограничения на распространение в некоторых странах или могут содержать закрытые части. Примерами являются фирменные драйверы для видеокарт Nvidia (restricted) или мультимедиа-кодеки, использующие патентованные в отдельных странах алгоритмы.

Каждый из компонентных каталогов разбит на "алфавитные" подкаталоги - от a до z. Исключение - библиотечные пакеты, сгруппированные в подкаталоги вида liba - libz. Внутри "алфавитных" подкаталогов имеются подкаталоги пакетные, а в них уже лежат отдельные deb-пакеты, представляющие собой конкретные сборки под определенные архитектуры.

Итак, состав предлагаемых репозиторием определённому дистрибутиву пакетов можно получить из файла url/dists/release_name/component/type/Packages, где url - url репозитория (в нашем случае - http://ru.archive.ubuntu.com/ubuntu/) release_name - имя релиза (в данном случае edgy), component - наименование компонента (main | restricted | universe | multiverse), type - тип пакета (binary | source), отражающий для бинарников ещё и архитектуру (binary-amd64, binary-powerpc).

Сколько компонентов и их типов предполагается использовать - столько потребуется и файлов Packages. Файлы эти, как было показано выше, легко читаемы, размер их сравнительно невелик. Так, для Ubuntu Edgy он составляет по 1,2 Мбайт (*.gz) или по 900 Кбайт (*.bz2) на каждый тип компонента main. Packages-файлы компонентов restricted и multiverse вообще не чувствительны (примерно по 5 и 100 килобайт). Наибольший "вес" дают типы компонента universe (3-4 Мбайт, в зависимости от компрессора), но и это не смертельно даже при модемном соединении.

Так вот, скачав где-либо нужные файлы Packages, перенеся их на целевую машину и поместив в каталог /var/lib/apt/lists, можно в даже при отсутствии Сети на ней, получить полную информацию о пакетах, предлагаемых репозиторием. Причем они будут доступны для любых программ управления deb-пакетами - утилит системы apt, aptitude, synaptic (Ubuntu и Xubuntu) или adept (Kubuntu).

Если скачать ещё и url/dists/your_distr/Release* - apt-утилиты перестанут "ругаться" по поводу "непроверенности" предлагаемых пакетов.

Названия файлов формируются просто, как "правда": url_dists_yourdistr_component_type_Packages То есть, например: au.archive.ubuntu.com_ubuntu_dists_dapper_main_binary-i386_Packages.

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

Все сказанное выше относилось к официальным репозиториям Ubuntu. Устройство репозиториев полу-официальных и совсем неофициальных может несколько отличаться в деталях. Причем "единство стиля" не всегда выдерживается даже внутри одного и того же репозитория. Например, в репозитории http://kubuntu.org/packages/ можно видеть дерево каталогов, где причудливо перемешаны подкаталоги отдельных пакетов различных версий (например, amarok), пакетных комплексов типа kde и koffice, их же для определенного релиза (например, hoary-kde341/ и так далее, hoary-koffice14/). Впрочем, это относится к ранним стадиям формирования репозитория. Ныне его структура устоялась, и каталоги последних версий marok, kde и koffice включат, как правило, подкаталог dists и отдельные подкаталоги для сборок под определенный релиз. Например, в состав каталога kde355 входят пулы сборок для Dapper и Edgy:

pool-dapper/
pool-edgy/

и так далее. Как сконструировать из них имена Packages-файлов - предоставляется читателю в качестве самостоятельного упражнения.

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

Настройка доступа к репозиториям пакетов

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

После обычной пользовательской установки Ubuntu и Kubuntu мы имеем доступ только к одному такому репозиторию - установочному CD или DVD. Причем первый нам практически не нужен - почти все его содержимое и так устанавливается по умолчанию в ходе первичной инсталляции. На DVD, конечно, есть большое количество дополнительных пакетов - но и ими не обойтись, кое-какие компоненты (те же аудио- и видеокодеки) можно получить только из репозиториев сетевых.

Источники пакетов, получаемых через apt, описываются в специальном конфигурационном файле - /etc/apt/sources.list. После пользовательской установки по умолчанию он содержит строку вида

deb cdrom:[Kubuntu 5.10 _Breezy Badger_ - Release i386 (20051012)]/ breezy main restricted

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

Формат каждой строки таков:

• тип пакета - deb для бинарников и deb-src для исходников;
• URL архива - в наших условиях это будет http://ru.archive.ubuntu.com/ubuntu;
• имя собственное дистрибутива - для текущей версии breezy (собственно дистрибутив), breezy-updates, breezy-backports, breezy-security (дополнительные компоненты;
• тип репозитория - main и restricted (основная часть дистрибутива, поддерживаемая командой обновления безопасности), universe и multiverse (дополнительная часть, лишенная соответствующей поддержки).

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

## Uncomment the following two lines to fetch updated software from the network
deb http://ru.archive.ubuntu.com/ubuntu breezy main restricted
deb-src http://ru.archive.ubuntu.com/ubuntu breezy main restricted

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

А можно поступить еще интересней: отказаться и от KDE, и от GNOME, установив, например, XFce - и таким образом преобразить свой дистрибутив в Xubuntu. Что, впрочем, уже реализовано официально.

Можно также заменить XFce на любой из полусотни имеющихся в репозитории менеджеров окон (например, Window Maker), после чего стать счастливым обладателем собственного уникального WMubuntu. В общем, перспективы индивидуализации системы открываются безграничные.

Кстати, не менее легко сменить релизную версию на тестируемую: для этого достаточно во всех строках файла /etc/apt/sources.list заменить breezy на dapper. А при необходимости воспользоваться репозиториями родительского Debian или какого-либо из его клонов - дописать соответствующие строки (руководствуясь документацией к требуемому дистрибутиву).

В случае, если коннект с репозиторием http://ru.archive.ubuntu.com/ubuntu оказывается неудовлетворительным (а подчас так и бывает), никто не запрещает добавить какие-либо иные зеркала официального репозитория. По моим наблюдениям, самыми быстрыми оказываются норвежское, бельгийское и нидерландское. Так что каждую строку с описанием отдельных репозиториев можно продублировать, заменив в URL ru на no, be или nl, соотвественно.

Сделанного достаточно, чтобы доустанавливать пакеты из дистрибутива, не включенные в комплект установочного компакт-диска, а также получать все штатные обновления. Однако время от времени появляются и обновления не вполне штатные. Так, текущая версия Kubuntu включает обычно KDE последней стабильной версии, которая при штатном обновлении остается неизменной (меняются только номера сборки пакетов). Однако в каждый момент времени для Kubuntu доступна и сборка KDE самой наипоследней версии, которая лежит в собственном репозитории, который подключается такой строкой:

deb http://kubuntu.org/packages/kde35 breezy main

После этого необходимо скачать gpg-ключ (нечто вроде гарантии идентичности):

$ wget http://people.ubuntu.com/~jriddell/kubuntu-packages-jriddell-key.gpg

и выполнить собственно процедуру идентификации:

$ sudo apt-key add kubuntu-packages-jriddell-key.gpg

Аналогично следует поступать и с другими "не вполне штатными" обновлениями, например, аудиоплейера amaroK. Следить за такими вещами проще всего по сайту проекта http://www.kubuntu.org. А по приводимым там ссылкам обычно содержится исчерпывающая информация о том, как подключать такие дополнительные репозитории.

И, наконец, для получения пакетов типа w32codecs и ему подобных, существуют уж совсем неофициальные репозитории, например, такой:

deb ftp://cipherfunk.org/pub/packages/ubuntu

Только, ради Бога, не подумайте, что это какой-то Linux'овый warez, ни в коем случае. Просто там помещаются пакеты, использующие алгоритмы, которые в некоторых осталых странах (типа США) защищаются всякого рода патентами. Семейство же дистрибутивов Ubuntu создавалось в расчете на международное распространение, и потому его разработчики вынуждены учитывать любые лицензионные ограничения всех стран мира.