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

Алексей Федорчук и Владимир Попов
март 2006 — январь 2007

В этой заметке описано внутреннее устройство пакетов deb-формата, а также организация их репозиториев в дистрибутивах Debian и Ubuntu.

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

Формат пакетов (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 — общие для всех дистрибутивов семейства, и располагаются они по адресу: archive.ubuntu.com/ubuntu. Это — «головное» хранилище пакетов, имеющее многочисленные региональные зеркала, принадлежность которых к стране указывается стандартным двухсимвольным префиксом, например:

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

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

Чтобы получить представление о внутреннем устройстве репозитория Ubuntu, посетим одно из его зекрал, например, 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 репозитория (в нашем случае — 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. Устройство репозиториев полу-официальных и совсем неофициальных может несколько отличаться в деталях. Причем «единство стиля» не всегда выдерживается даже внутри одного и того же репозитория. Например, в репозитории 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 или какого-либо из его клонов — дописать соответствующие строки (руководствуясь документацией к требуемому дистрибутиву).

В случае, если коннект с репозиторием 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. Следить за такими вещами проще всего по сайту проекта www.kubuntu.org. А по приводимым там ссылкам обычно содержится исчерпывающая информация о том, как подключать такие дополнительные репозитории.

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

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

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