Купить недорого дубликаты водительских права pravakupiaf.com. . Авторские туры по армении в 2024 traveler.market. . Цена на доставку песка transstroyrnd.ru.

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

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

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

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

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

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

Сначала — пара слов о репозиториях Ubuntu вообще. Официальные репозитории Ubuntu — общие для всех дистрибутивов семейства, и располагаются они здесь. Это — “головное” хранилище пакетов, имеющее многочисленные региональные зеркала, принадлежность которых к стране указывается стандартным двухсимвольным префиксом, например:

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

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

Чтобы получить представление о внутреннем устройстве репозитория 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/ (то есть “пула” пакетов). Здесь мы видим всего четыре подкаталога, соответствующие указанным выше компонетам дистрибутива:

  1. main/
  2. restricted/
  3. universe/
  4. multiverse/

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

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

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

Каждый из компонентных каталогов разбит на “алфавитные” подкаталоги — от a до z. Исключение — библиотечные пакеты, сгруппированные в подкаталоги вида libalibz. Внутри “алфавитных” подкаталогов имеются подкаталоги пакетные, а в них уже лежат отдельные 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. Устройство репозиториев полу-официальных и совсем неофициальных может несколько отличаться в деталях. Причем “единство стиля” не всегда выдерживается даже внутри одного и того же репозитория. Например, в репозитории Kubuntu можно видеть дерево каталогов, где причудливо перемешаны подкаталоги отдельных пакетов различных версий (например, amarok), пакетных комплексов типа kde и koffice, их же для определенного релиза (например, hoary-kde341/ и так далее, hoary-koffice14/). Впрочем, это относится к ранним стадиям формирования репозитория. Ныне его структура устоялась, и каталоги последних версий amarok, kde и koffice включат, как правило, подкаталог dists и отдельные подкаталоги для сборок под определенный релиз. Например, в состав каталога kde355 входят пулы сборок для Dapper и Edgy:

pool-dapper/
pool-edgy/

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

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


Теги: , ,