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

Оригинал: DragonFly - Packaging up the UserLand
Перевод: Валерий Винник, 05.01.31

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

Нам нужна возможность и роскошь обновлять только необходимый пакет, не затрагивая приложений, которые от этого пакета зависят. Нельзя сказать, что это желательно. Вместо этого мы говорим, что это необходимо, поскольку даст нам возможность производить дискретные обновления (а также поддержание на актуальном уровне самой базы данных системы управления пакетами), не боясь вмешательства третьей силы в процесс. Иногда нам, возможно, и придётся всё синхронизировать самим, однако могут быть и периоды продолжительностью от нескольких дней до нескольких месяцев, когда одни пакеты будут обновляться нормально, а другие очень крупные пакеты будут терять актуальность из-за старых, долго не обновлявшихся версий библиотек. Нам нужно суметь решить эту проблему. Нам также необходимо научиться поддерживать разные версии каталогов конфигурации/поддержки, которые могут быть жёстко закодированы портом. Всякий раз при возникновении такого конфликта система управления пакетами также должна проверять версии каталогов поддержки. Если две несовместимые версии пакета Х требуют /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 job будет отвечать за передвижение по системе и локализацию всякого "хлама", который может быть удалён после того, как вы обновили все пакеты, обычно от этого "хлама" зависимые.

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

Обновлено: 12.03.2015