DragonFly - Управление пакетами

Оригинал: DragonFly - Packaging up the UserLand
Перевод: Lao, редакция от 05.06.01
1-я редакия от 05.01.31 - Unix.ginras.ru

К настоящему времени в приложениях накопился такой беспорядок, что трудно сделать систему пакетирования и инсталляции, позволяющую добиться гладкой установки и безупречного функционирования. Мы пришли к выводу, что главная проблема - это то, что даже небольшие изменения в библиотеках от сторонних разработчиков (над которыми мы не имеем контроля) могут причинить вред уже установленному приложению. Система управления пакетами МОЖЕТ пройтись по дереву зависимостей и обновить все, что нуждается в обновлении. Проблема состоит в том, что у системы управления пакетами может отсутствовать новая версия пакета или пакетов, которые необходимо обновить вследствие произошедшего уже обновления какой-то библиотеки от стороннего разработчика.

Нам нужна возможность обновлять только необходимый пакет, не затрагивая приложения, которые от этого пакета зависят. Нельзя сказать, что это желательно. Скорее, это необходимо, поскольку позволяет нам производить частичные обновления (а также частичные обновления базы данных самой системы управления пакетами), не боясь вмешательства в процесс третьей силы. В конце концов мы все синхронизуем, но могут возникать периоды продолжительностью от нескольких дней до нескольких месяцев, когда некоторые пакеты не будут синхронизованы, а для некоторых очень крупных пакетов будет сохраняться зависимость от старой версии некоторой библиотеки в течение долгого времени. Нам нужно это поддерживать. Нам также необходимо научиться поддерживать разные версии каталогов конфигурации/поддержки, которые могли бы подключаться путем портирования. Всякий раз при возникновении таких конфликтов система управления пакетами должна й пакета Х требуется /usr/local/etc/X, мы выйдем из положения, объявив /usr/local/etc/X:VERSION1 и /usr/local/etc/X:VERSION2.

Этой цели можно добиться, тщательно отслеживая зависимости между версиями и присваивая бинарным пакетам соответствующие среде "ярлыки". Оверлейная структура файловой системы - так вы можете назвать необходимость поддержки каталогов вроде /usr/lib/, /usr/local/lib/, даже /usr/local/etc - дает возможность пакету видеть только необходимые ему версии библиотек и/или файлов. Все остальное такому пакету видно не будет. При наличии поддержки видимости пакета, вы сразу узнаете, правильно ли вы определили зависимости, так как этот пакет не сможет найти неправильно размещенные библиотеки или файлы поддержки, поскольку при установке пакета последнему не были переданы права доступа к ним. Например, если пакет сообщает, что программа зависит от библиотеки ncurses library версии 1.5, то именно эта "версия 1.5" только и будет видна программе (а восприниматься программой будет как libncurses.*).

Используя такую систему, мы сможем инсталлировать разные версии чего бы то ни было вне зависимости от того, поддерживается ли управление версиями на уровне мелких компонетов, и даже в тех случаях, когда (как в обычной системе) имеются конфликты. Система управления пакетами будет ответственна за "маркировку" бинарных файлов, а операционная система будет регулировать их видимость. Система управления пакетами либо даже просто задание cron будет отвечать за передвижение по системе и локализацию всякого "хлама", который может быть удален после того, как вы обновили все пакеты, ранее зависимые от этого "хлама".

Другое крупное преимущество использования принципа видимости состоит в том, что это дает нам возможность четко определить, нуждается ли пакет в чем-нибудь вообще. Нам не придется полагаться на систему управления пакетами при определении возможных зависимостей - ведь должно быть достаточно посмотреть на "ярлык" среды, прикрепленный к бинарному файлу!