понедельник, 8 сентября 2008 г.

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

Я обыгрывать люблю всех подряд.
Королевой королю шах и мат.
И живу я хорошо - лучше всех.
Не случайно он пришел, мой успех.
Владимир Асмолов

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

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

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

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

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

Сначала - пара слов о репозиториях Ubuntu вообще. Официальные репозитории Ubuntu - общие для всех дистрибутивов семейства, и располагаются они по адресу: http://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);
  • R
  • ecommends: рекомендуемые, то есть мягкие, зависимости;
  • 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) достигается в онлайновом режиме. Настройка онлайнового доступа к репозиториям будет предметом следующей заметки.

Комментариев нет:

Неактивный атрибут "скрытый" или как снять атрибут скрытый после вируса

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