Urpmi, rpmdrake и автоматический выбор зависимостей

Материал из Rosalab Wiki
Перейти к: навигация, поиск

Одной из особенностей репозиториев нашей ОС является наличие пакетов, зависимости которых могут быть разрешены несколькими способами — поскольку для некоторых зависимостей присутствует несколько пакетов, их предоставляющих. Почему так происходит? Поясню на примере.

Есть у нас в репозиториях система распознавания символов (OCR) Tesseract. Ей для работы необходимы пакеты с данными для конкретных языков. Tesseract сейчас поддерживает более 70 языков, и для каждого из них у нас отдельный пакет. Однако вся эта куча языков пользователю вряд ли понадобится — большинству достаточно поддержки родного для них языка. Поэтому при установке tesseract надо каким-то образом решить — какие языковые пакеты надо поставить. Непосредственно на уровне пакетов этот вопрос решается следующим образом: сам пакет tesseract требует абстрактную зависимость tesseract-language, а ее предоставляет каждый из соответствующих языковых пакетов.

При установке tesseract, urpmi (или rpmdrake) видят, что зависимость tesseract-language может быть разрешена несколькими способами. В такой ситуации они либо спрашивают пользователя, какой пакет выбрать, либо, в случае выставления опции --auto (или аналогичной галочки в настройках rpmdrake), выбирают один из пакетов самостоятельно.

Rpmdrake auto.png
Strange food menus.jpg

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

Кстати,

При установке пакетов, вы предпочитаете автоматический или ручной выбор зависимостей?

Автоматический14
88%
Ручной2
13%
Когда как0
0%


Так как же работает автоматический выбор?

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

Раньше, для разрешения зависимости urpmi просто выбирал первый попавшийся пакет. Встречается мнение, что выбор происходит случайным образом, однако это не так — пакеты при выборе упорядочиваются согласно их внутренним идентификаторам, которые использует urpmi в своей работе, и изначально urpmi выбирал пакет с наименьшим идентификатором. Однако нет гарантии, что в разных системах эти идентификаторы будут идентичны (поскольку идентификаторы присваиваются при считывании данных о пакетах в репозиториях, а у пользователей могут быть подключены разные репозитории и в разном порядке).

Как результат, при установке одного и того же пакета с опцией '--auto' в разных системах зависимости пакета могут быть разрешены по-разному. В принципе, большой проблемы в этом нет — например, если пакету нужна Java, и он работает как с OpenJDK 6, так и с OpenJDK 7, то пользователю должно быть безразлично, какую версию OpenJDK выберет urpmi. Тем не менее, хотелось бы иметь более унифицированное поведение в разных системах, и при этом более умное — чтобы избежать хотя бы часть ситуаций, когда некоторый пакет предоставляет что-то по ошибке (ведь мэйнтейнеры тоже люди, они могут ошибиться сами или, что более вероятно, пропустить ошибку автоматического генератора зависимостей).

Чтобы убить двух зайцев сразу, мы реализовали в urpmi выбор пакета с именем, содержащим наибольшую общую строку с затребованной зависимостью. То есть если некоторому пакету требуется 'java', то будет выбран 'java-openjdk-1.6.0' или 'java-openjdk-1.7.0', но не 'cacao' или другие экзотические java-машины. Конечно, полной однозначности все равно добиться не удастся (как видно на примере той же java), но как показал практика, такой эвристический алгоритм в реальной жизни дает лучшие результаты, чем просто выбор первого попавшегося пакета.

Однако есть ситуации, в которых пользователю не так уж и безразлично, что выберет инструмент управления пакетами. Самый распространенный случай — это выбор пакетов, зависящих от языка системы. Так, в приведенном в начале примере с tesseract, пользователь будет рад увидеть поддержку родного языка (ну в крайнем случае — английского), а не какого-нибудь древнеиспанского[1]. Для разрешения таких ситуаций необходимо решить две задачи:

  1. объяснить urpmi, что выбор пакета должен зависеть от языковых настроек системы;
  2. со стороны urpmi, выбрать пакет, соответствующий текущим настройкам ОС.

Первая задача решается посредством добавления пакетам зависимостей на соответствующие пакеты с системной локализацией — так что tesseract-rus зависит от locales-ru, tesseract-eng — от locales-en и так далее.

Решение второй задачи осуществляется urpmi в два этапа — сначала он смотрит, какие locales-* пакеты уже установлены в системе (помимо locales-en). Если таких пакетов несколько, то дополнительно анализируется настройка локали системы (точнее, значение переменной LANG).

Мы реализовали такой «двойной проход», поскольку пользователи у нас очень разные и подходы к настройке системы у них тоже разные. Кто-то сразу работает в полностью локализованной системе, а кто-то предпочитает видеть меню и справку на английском, но при этом работает с документами преимущественно на родном языке. Как угодить всем сразу — мы еще до конца не придумали, идеи приветствуются:)

Перечисленные изменения затрагивают и ситуацию, когда urpmi спрашивает пользователя, какой пакет выбрать — в таком случае вверху списка всегда показывается пакет, который сам urpmi выбрал бы при использовании опции '--auto'. Более того, в случае выбора языковых пакетов, urpmi даже не предложит пакеты, для которых в системе не установлены соответствующие locales-*. Например, у меня в системе стоят locales-ru, locales-en, locales-da и locales-ja. При этом системная локаль — русская. В такой ситуации, «urpmi tesseract» предложил мне следующий выбор:

Urpmi auto.png

Как видим, первым идет русский вариант, за ним — пакеты, зависящие от локалей, отличных от английской, а в конце — пакеты, зависящие от locales-en (Тагальский и язык Чероки зависят от locales-en, поскольку для них просто не нашлось соответствующих локалей, а вот heb-com должен зависеть от locales-he; вот и баг нашли заодно:)). Пакеты, зависящие от других локалей, в список вообще не попадают.

Отмечу, что некоторые изменения реализованы только в urpmi, но не в rpmdrake — поскольку на смену последнему мы готовим новый центр управления приложениями, о котором мы обязательно расскажем в следующий раз.
  1. Конечно, если пользователь — не специалист, работающий в соответствующей области

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.