Просмотр исходного текста страницы LXF169:Репозитории

[[Главное в мире Linux]]
== Репозитории: Храним пакеты ==
''Андрей Пономаренко и Владимир Рубанов исследуют тонкости поддержки пакетных репозиториев в дистрибутивах Linux.''
 [[Файл: LF3_opt.jpeg| right  |thumb|400px| > Визуализация процесса разработки репозитория с помощью 
CodeSwarm.  ]]
Ключевым направлением развития любого современного дистрибутива Linux является предоставление пользователям наибольшего разнообразия программ на любой вкус. Для быстрой и удобной установки программ в дистрибутивах используются RPM- или Deb-пакеты, которые хранятся в специальных репозиториях на удаленных серверах в интернете или на установочном диске. Каждый пакет представляет собой заранее собранную из исходных кодов программу, готовую к использованию. Количество пакетов в репозитории может быть более 10000! Сборкой же пакетов занимаются так называемые мейнтейнеры дистрибутива. Это могут быть как энтузиасты из мирового сообщества, так и штатные специалисты компании – поставщика дистрибутива. И нелегок их труд.

===Виды репозиториев===

Общее количество программ в типичном современном дистрибутиве Linux – порядка десяти тысяч. Большинство из них хранятся в репозиториях, и только часть наиболее востребованных программ идет на установочных дисках. Для создания, сборки и дальнейшего обновления такого большого количества пакетов отводятся существенные человеческие ресурсы. Тем не менее, на поддержку всех пакетов в репозиториях, как правило, ресурсов все равно не хватает. По этой причине репозитории разделяют на две фундаментальные части: главный (main) и второстепенный (contrib). За каждым пакетом в главном репозитории должен быть закреплен определенный мейнтейнер, который будет следить за его состоянием. Пакеты же из второстепенного репозитория поддерживаются не постоянно – любыми членами сообщества дистрибутива, у которых появляется на это свободное время.

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

Стоит заметить, что конкретные названия репозиториев могут различаться в разных дистрибутивах. Например, main-репозиторий в Fedora называют core-репозиторием, а restricted-репозиторий в дистрибутиве Mageia называют tainted-репозиторием.

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

Чтобы можно было быстро считывать основную информацию о доступных пакетах, в репозиториях хранятся так называемые метафайлы. В них содержится информация о названиях, версиях, зависимостях и содержании пакетов. Исторически формат таких файлов различается в разных дистрибутивах. Например, в дистрибутиве ROSA это hdlist-файлы, а в Fedora – repodata-файлы.

===Правила пакетирования===

Чтобы поддерживать структуру дистрибутива и упростить процесс разработки, вводятся специальные правила (policy) для создания и обновления пакетов. Например, они описывают пути установки разных типов файлов программы в системе, правильный выбор имен пакетов в зависимости от их содержимого, и т. д. Все это в дальнейшем позволяет легче ориентироваться в системе и работать продуктивнее.

===Тестирование пакетов===

К сожалению, не все процессы по созданию пакетов достаточно автоматизированы, чтобы не возникало ошибок в пакетах. Для их поиска используются автоматические тесты, проверяющие соответствие содержимого пакетов установленным политикам. Одним из наиболее известных и универсальных инструментов для тестирования RPM-пакетов является Rpmlint [1]. Этот инструмент проверяет содержимое и атрибуты пакетов на соответствие нескольким сотням правил. Правила могут быть отключены, дополнены или изменены, чтобы соответствать политике конкретного дистрибутива. В зависимости от количества нарушенных правил пакету присваивается определенный уровень негодности (badness). Если негодность пакета больше некоторого заранее определенного уровня, то пакет необходимо исправлять. Допустимый же уровень негодности можно варьировать в зависимости от доступного количества мейнтейнеров, сроков выпуска дистрибутива и количества поддерживаемых пакетов. Аналогом данного инструмента для дистрибутивов, использующих Deb-пакеты, является Deblint [2]. Для репозитория главное, чтобы все пакеты в репозитории собирались, устанавливались и работали.

===Замкнутость репозитория===
[[Файл: | right  |thumb|300px|   ]]
Важнейшимм требованием к пакетным репозиторям является возможность безошибочной установки всех пакетов на компьютер пользователя. Проблемы с установкой пакетов могут возникать по разным причинам – например, если один пакет требует для работы несколько других, при этом одного из них по какой-то причине нет в репозитории. Такое явление называют неразрешенной зависимостью. Причиной их возникновения может служить как ошибка мейнтейнера, так и сбой в применяемых инструментах. Для контроля таких ошибок используются статические анализаторы замкнутости репозитория, т. е. наличия всех пакетов, требуемых другими пакетами. К сожалению, в силу существенных различий форматов репозиториев у разных дистрибутивов пока еще нет универсального инструмента для проверки замкнутости. Например, в таких дистрибутивах, как Mandriva или ROSA, используется инструмент urpm-repoclosure [3], а в Debian и Ubuntu используется инструмент под названием debcheck [4].

===Конфликты по файлам===

Еще одной причиной, препятствующей установке пакетов, может быть конфликт по файлам с другими установленными пакетами, т. е. когда один пакет пытается установить файл с тем же имененем и по тому же пути, что и другой пакет. Иногда такая ситуация бывает допустимой – например, когда два пакета предоставляют две разные реализации виртуальной Java-машины или две разные реализации одной из стандартных библиотек. В таких случаях наличие конфликта должно быть отражено в свойствах пакета. Иначе конфликтующие файлы следует переименовать, обусловив корректную одновременную установку пакетов.

===Кольцевые зависимости===

Немаловажной проблемой пакетных репозиториев также являются кольцевые зависимости, т. е. зависимости вида A → B → C → A. Опять же, такие зависимости могут быть допустимы, когда одному пакету действительно требуется для работы другой, а тому нужен первый, но их нельзя поместить в единый пакет из-за политики именования и разделения программ на пакеты. В других случаях это может быть индикатором неправильно описанных зависимостей между пакетами. Причиной тут может быть не только человеческий фактор, но и некорректная работа автоматического генератора зависимостей у используемого пакетного менеджера. Это приводит к большим дополнительным временным затратам установщика пакетов и, возможно, к неправильному порядку установки пакетов из кольца.

Кольцевые зависимости можно находить с помощью специальных инструментов анализа. Например, в дистрибутиве ROSA для этого используется инструмент urpm-repograph [5].

===Чистка репозитория===

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

===Популярность пакетов===
{{Врезка|right|Ширина=40%|Заголовок=Полезные ссылки |Содержание=
1	http://rpmlint.zarb.org/

2	http://www.debian.org/doc/manuals/programmer/ch-tools.html

3	http://wiki.rosalab.ru/en/index.php/Urpm-tools#urpm-repoclosure

4	http://qa.debian.org/debcheck.php

5	http://wiki.rosalab.ru/en/index.php/Urpm-tools#urpm-repograph

6	http://popcon.debian.org/

7	http://wiki.rosalab.ru/en/index.php/ROSA_Developer_QuickStart

8	http://www.debian.org/doc/manuals/developers-reference/ }}
Из-за ограниченности человеческих ресурсов, выделяемых на поддержку пакетных репозиториев, перед мейнтейнерами всегда стоит задача выбора набора пакетов, которым надо уделять внимание в первую очередь. Наиболее важные пакеты определяются либо по количеству других пакетов, зависящих от данного (обратных зависимостей), либо по количеству пользователей, использующих данный пакет (популярности пакета). Количество обратных зависимостей всегда можно подсчитать на основе анализа только репозитория. Для оценки же популярности пользователям предлагают установить дополнительный пакет, который будет сообщать разработчикам об используемых ими программах. Например, в системе Debian этот пакет называется popcon [6].

===Заключение===

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

Именно поэтому для новых членов сообщества и мейнтейнеров разработчики дистрибутивов часто создают вводные Wiki-страницы (см. например [7] в ROSA или [8] в Debian), на которых собрана информация о правилах работы с пакетами в данном дистрибутиве, использовании инструментов, автоматических тестах, возможных ошибках и способах их предотвращения и исправления. Такие знания наряду с собственно средствами автоматизации процессов разработки и тестирования помогают существенно улучшить качество дистрибутива. |