Urpmi, rpmdrake и автоматический выбор зависимостей
Одной из особенностей репозиториев нашей ОС является наличие пакетов, зависимости которых могут быть разрешены несколькими способами — поскольку для некоторых зависимостей присутствует несколько пакетов, их предоставляющих. Почему так происходит? Поясню на примере.
Есть у нас в репозиториях система распознавания символов (OCR) Tesseract. Ей для работы необходимы пакеты с данными для конкретных языков. Tesseract сейчас поддерживает более 70 языков, и для каждого из них у нас отдельный пакет. Однако вся эта куча языков пользователю вряд ли понадобится — большинству достаточно поддержки родного для них языка. Поэтому при установке tesseract надо каким-то образом решить — какие языковые пакеты надо поставить. Непосредственно на уровне пакетов этот вопрос решается следующим образом: сам пакет tesseract требует абстрактную зависимость tesseract-language, а ее предоставляет каждый из соответствующих языковых пакетов.
При установке tesseract, urpmi (или rpmdrake) видят, что зависимость tesseract-language может быть разрешена несколькими способами. В такой ситуации они либо спрашивают пользователя, какой пакет выбрать, либо, в случае выставления опции --auto (или аналогичной галочки в настройках rpmdrake), выбирают один из пакетов самостоятельно.
К слову, в последних версиях автоматический выбор зависимостей включен в Rpmdrake по умолчанию, ибо для большинства пользователей вопросы выбора пакетных альтернатив выглядели как выбор еды в кафе с меню на клингонском — ничего не понятно, а если выберешь что-то не то — еще и будешь виноват.
Кстати,
При установке пакетов, вы предпочитаете автоматический или ручной выбор зависимостей?
|
Так как же работает автоматический выбор?
Алгоритм работы автоматического разрешения зависимостей является загадкой для большинства пользователей, да честно говоря, и для многих специалистов. Попробуем приоткрыть завесу тайны.
Раньше, для разрешения зависимости 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]. Для разрешения таких ситуаций необходимо решить две задачи:
- объяснить urpmi, что выбор пакета должен зависеть от языковых настроек системы;
- со стороны 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» предложил мне следующий выбор:
Как видим, первым идет русский вариант, за ним — пакеты, зависящие от локалей, отличных от английской, а в конце — пакеты, зависящие от locales-en (Тагальский и язык Чероки зависят от locales-en, поскольку для них просто не нашлось соответствующих локалей, а вот heb-com должен зависеть от locales-he; вот и баг нашли заодно:)). Пакеты, зависящие от других локалей, в список вообще не попадают.
Отмечу, что некоторые изменения реализованы только в urpmi, но не в rpmdrake — поскольку на смену последнему мы готовим новый центр управления приложениями, о котором мы обязательно расскажем в следующий раз.- ↑ Конечно, если пользователь — не специалист, работающий в соответствующей области
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.