http://wiki.rosalab.com/ru/index.php?title=%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/Urpmi,_rpmdrake_%D0%B8_%D0%B0%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%B2%D1%8B%D0%B1%D0%BE%D1%80_%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D0%B5%D0%B9&feed=atom&action=historyБлог:Точка Росы/Urpmi, rpmdrake и автоматический выбор зависимостей - История изменений2024-03-28T15:27:04ZИстория изменений этой страницы в викиMediaWiki 1.26.4http://wiki.rosalab.com/ru/index.php?title=%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%A0%D0%BE%D1%81%D1%8B/Urpmi,_rpmdrake_%D0%B8_%D0%B0%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%B2%D1%8B%D0%B1%D0%BE%D1%80_%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D0%B5%D0%B9&diff=10171&oldid=prevStanislav.fomin в 23:46, 22 августа 20132013-08-22T23:46:35Z<p></p>
<p><b>Новая страница</b></p><div>Одной из особенностей репозиториев нашей ОС является наличие пакетов, зависимости которых могут быть разрешены несколькими способами — поскольку для некоторых зависимостей присутствует несколько пакетов, их предоставляющих. Почему так происходит? Поясню на примере.<br />
<br />
Есть у нас в репозиториях система распознавания символов (OCR) <tt>Tesseract</tt>.<br />
Ей для работы необходимы пакеты с данными для конкретных языков. <tt>Tesseract</tt> сейчас поддерживает более 70 языков, и для каждого из них у нас отдельный пакет.<br />
Однако вся эта куча языков пользователю вряд ли понадобится — большинству достаточно поддержки родного для них языка. Поэтому при установке <tt>tesseract</tt> надо каким-то образом решить — какие языковые пакеты надо поставить.<br />
Непосредственно на уровне пакетов этот вопрос решается следующим образом: сам пакет <tt>tesseract</tt> требует абстрактную зависимость '''tesseract-language''', а ее предоставляет каждый из соответствующих языковых пакетов.<br />
<br />
При установке <tt>tesseract</tt>, <tt>urpmi</tt> (или <tt>rpmdrake</tt>) видят, что зависимость '''tesseract-language''' может быть разрешена несколькими способами.<br />
В такой ситуации они либо спрашивают пользователя, какой пакет выбрать,<br />
либо, в случае выставления опции <tt>--auto</tt> (или аналогичной галочки в настройках <tt>rpmdrake</tt>), выбирают один из пакетов самостоятельно.<br />
<br />
[[File:rpmdrake_auto.png|center]]<br />
<br />
<blockquote><br />
[[File:Strange food menus.jpg|256px|right]]<br />
<br />
К слову, в последних версиях автоматический выбор зависимостей включен в <tt>Rpmdrake</tt> по умолчанию, ибо для большинства пользователей вопросы выбора пакетных альтернатив выглядели как выбор еды в кафе с меню на клингонском — ничего не понятно, а если выберешь что-то не то — еще и будешь виноват. <br />
</blockquote><br />
<br />
Кстати,<br />
<poll> <br />
ALTERNATIVE<br />
OPEN_RESULTS<br />
При установке пакетов, вы предпочитаете автоматический или ручной выбор зависимостей?<br />
Автоматический<br />
Ручной<br />
Когда как<br />
</poll><br />
<br />
<br />
=== Так как же работает автоматический выбор? ===<br />
<br />
Алгоритм работы автоматического разрешения зависимостей является загадкой для большинства пользователей, да честно говоря, и для многих специалистов. Попробуем приоткрыть завесу тайны.<br />
<br />
Раньше, для разрешения зависимости <tt>urpmi</tt> просто выбирал первый попавшийся пакет. Встречается мнение, что выбор происходит случайным образом, однако это не так — пакеты при выборе упорядочиваются согласно их внутренним идентификаторам, которые использует <tt>urpmi</tt> в своей работе, и изначально <tt>urpmi</tt> выбирал пакет с наименьшим идентификатором. Однако нет гарантии, что в разных системах эти идентификаторы будут идентичны (поскольку идентификаторы присваиваются при считывании данных о пакетах в репозиториях, а у пользователей могут быть подключены разные репозитории и в разном порядке).<br />
<br />
Как результат, при установке одного и того же пакета с опцией '<tt>--auto</tt>' в разных системах зависимости пакета могут быть разрешены по-разному. В принципе, большой проблемы в этом нет — например, если пакету нужна Java, и он работает как с OpenJDK 6, так и с OpenJDK 7, то пользователю должно быть безразлично, какую версию OpenJDK выберет <tt>urpmi</tt>.<br />
Тем не менее, хотелось бы иметь более унифицированное поведение в разных системах, и при этом более умное — чтобы избежать хотя бы часть ситуаций, когда некоторый пакет предоставляет что-то по ошибке (ведь мэйнтейнеры тоже люди, они могут ошибиться сами или, что более вероятно, пропустить ошибку автоматического генератора зависимостей).<br />
<br />
Чтобы убить двух зайцев сразу, мы реализовали в <tt>urpmi</tt> выбор пакета с именем, содержащим наибольшую общую строку с затребованной зависимостью. То есть если некоторому пакету требуется '<tt>java</tt>', то будет выбран '<tt>java-openjdk-1.6.0</tt>' или '<tt>java-openjdk-1.7.0</tt>', но не '<tt>cacao</tt>' или другие экзотические java-машины. Конечно, полной однозначности все равно добиться не удастся (как видно на примере той же java), но как показал практика, такой эвристический алгоритм в реальной жизни дает лучшие результаты, чем просто выбор первого попавшегося пакета.<br />
<br />
Однако есть ситуации, в которых пользователю не так уж и безразлично, что выберет инструмент управления пакетами. Самый распространенный случай — это выбор пакетов, зависящих от языка системы. Так, в приведенном в начале примере с <tt>tesseract</tt>, пользователь будет рад увидеть поддержку родного языка (ну в крайнем случае — английского), а не какого-нибудь древнеиспанского<ref>Конечно, если пользователь — не специалист, работающий в соответствующей области</ref>. Для разрешения таких ситуаций необходимо решить две задачи:<br />
# объяснить urpmi, что выбор пакета должен зависеть от языковых настроек системы;<br />
# со стороны urpmi, выбрать пакет, соответствующий текущим настройкам ОС.<br />
<br />
Первая задача решается посредством добавления пакетам зависимостей на соответствующие пакеты с системной локализацией — так что '''tesseract-rus''' зависит от '''locales-ru''', '''tesseract-eng''' — от '''locales-en''' и так далее.<br />
<br />
Решение второй задачи осуществляется <tt>urpmi</tt> в два этапа — сначала он смотрит, какие locales-* пакеты уже установлены в системе (помимо <tt>locales-en</tt>). Если таких пакетов несколько, то дополнительно анализируется настройка локали системы (точнее, значение переменной <tt>LANG</tt>).<br />
<br />
Мы реализовали такой «двойной проход», поскольку пользователи у нас очень разные и подходы к настройке системы у них тоже разные. Кто-то сразу работает в полностью локализованной системе, а кто-то предпочитает видеть меню и справку на английском, но при этом работает с документами преимущественно на родном языке. Как угодить всем сразу — мы еще до конца не придумали, идеи приветствуются:)<br />
<br />
Перечисленные изменения затрагивают и ситуацию, когда <tt>urpmi</tt> спрашивает пользователя, какой пакет выбрать — в таком случае вверху списка всегда показывается пакет, который сам <tt>urpmi</tt> выбрал бы при использовании опции '<tt>--auto</tt>'.<br />
Более того, в случае выбора языковых пакетов, <tt>urpmi</tt> даже не предложит пакеты, для которых в системе не установлены соответствующие locales-*. Например, у меня в системе стоят <tt>locales-ru</tt>, <tt>locales-en</tt>, <tt>locales-da</tt> и <tt>locales-ja</tt>. При этом системная локаль — русская. В такой ситуации, «<tt>urpmi tesseract</tt>» предложил мне следующий выбор:<br />
<br />
[[File:urpmi_auto.png|center]]<br />
<br />
Как видим, первым идет русский вариант, за ним — пакеты, зависящие от локалей, отличных от английской, а в конце — пакеты, зависящие от <tt>locales-en</tt> (Тагальский и язык Чероки зависят от <tt>locales-en</tt>, поскольку для них просто не нашлось соответствующих локалей, а вот <tt>heb-com</tt> должен зависеть от <tt>locales-he</tt>; вот и баг нашли заодно:)). Пакеты, зависящие от других локалей, в список вообще не попадают.<br />
<br />
Отмечу, что некоторые изменения реализованы только в <tt>urpmi</tt>, но не в <tt>rpmdrake</tt> — поскольку на смену последнему мы готовим новый центр управления приложениями, о котором мы обязательно расскажем в следующий раз.<br />
<br />
[[Category:ToROSAPoint]]<br />
{{wl-publish: 2013-08-22 12:19:32 +0400 | Denis.silakov }}</div>Stanislav.fomin