DKWSLabs

rdog

Nix – инструмент, помогающий выбраться из «ада зависимостей»
Оригинал: "Nix fixes dependency hell on all Linux distributions"
Авторы: Pjotr Prins, Jeeva Suresh, Eelco Dolstra
Перевод: Юрий Овчаренко
Дата перевода: 25 января 2009 г.
Пакетный менеджер следующего поколения Nix, это инструмент, предлагающий простой подход для управления бинарными пакетами и пакетами на основе исходных кодов независимо от версии вашего дистрибутива, будь то Ubuntu, Debian, Suse, Fedora или Rad Hat. Более того, Nix не конфликтует со штатным пакетным менеджером вашего дистрибутива. В отличие от большинства пакетных менеджеров, Nix позволяет установить параллельно несколько версий одного и того же пакета, при этом избежать конфликтов и сохранить возможность откатов установленых обновлений. Это удобный инструмент для системного администрирования в условиях гетерогенной (неоднородной) среды а так же для разработчиков, пишущих ПО с поддержкой разных версий библиотек, компиляторов и интерпретаторов.
Зачем же нам нужен еще один пакетный менеджер? Потому что существующие недостаточно хорошо справляются со своими задачами в условиях постоянного обновления пакетов в системе. Рано или поздно пользователь сталкивается с проблемой неудовлетворенных зависимостей. По этой причине в частности, многие пользователи предпочитают отказаться от обновления своей системы с выходом её новой версии, предпочитая переустановить систему «с нуля». Nix делает процесс обновления безопаснее, попросту не позволяет перезаписывать уже установленные пакеты и таким образом предоставляет возможность продолжать пользоваться предыдущей версией программы параллельно с установленной новой версией, а в случае необходимости легко осуществить откат.
Проект Nix родился в Университете Утрехта в Нидерландах, название происходит от голландского «ничто».
Проблема: деструктивные обновления, несовместимости версий, разнородное окружение
Все популярные пакетные менеджеры, включая APT, RPM и систему портов FreeBSD, подвержены проблеме деструктивных обновлений пакетов ПО. Когда вы производите обновление, будь то апдейт одного пакета или системы целиком, пакетный менеджер перезаписывает установленные файлы их новыми версиями. До тех пор, пока обратная совместимость между версиями файлов сохраняется, проблем не возникает, но к сожалению в реальности пакеты не обладают свойством обратной совместимости.
Предположим к примеру, что вы решили обновить браузер Firefox и ваш пакетный менеджер решил, что необходимо так же обновить библиотеки GTK. Если новая версия GTK не имеет достаточной обратной совместимости, вы рискуете столкнуться с тем, что некоторые установленные ранее пакеты перестанут работать. В Windows-системах подобная проблема называется «адом dll», в мире UNIX эту проблему называют «адом зависимостей» (dependency hell) и здесь она является много более актуальной, поскольку программы в *nix системах как правило имеют много внешних зависимостей
Деструктивные обновления также затрудняют отмену или «откат» произведенных в системе обновлений, до тех пор, пока вы или ваш пакетный менеджер не позаботились о резервном копировании файлов, перезаписываемых в процесе установки обновлений.
Наконец во время того, как менеджер занят установкой новых версий пакетов и перезаписыванием существующих файлов, система находится в нестабильном состоянии, в котором не гарантируется нормальная работа установленных программ. Попробуйте выключить питание компьютера во время очередного обновления вашей системы и посмотрите, сможет ли после этого система загрузиться! (Прим. переводчика: лучше поверьте автору на слово и не проверяйте Wink

)
Обычно обновление пакета делает недоступным установленный ранее пакет предыдущей версии. Иногда однако менеджеры пакетов дают возможность установить новую версию параллельно со старой, скажем пакеты gcc-3.4 и gcc-4.3. Однако это работает только в том случае, если менеджер позаботился о том, чтобы разные версии пакетов были установлены в разных местах. Как быть если вы хотите попробовать gcc-4.0.3, не повредив при этом установленную версию компилятора? Или вам необходимо протестировать ПО, используя различные версии компиляторов, библиотек, интерпретаторов и их комбинаций? Как вам посмотреть на новую бета-версию любимой программы, не рискуя при этом уже установленной более ранней версией?
Далее имеется проблема поддержки ПО в разных дистрибутивах. Разработчики и системные администраторы не могут знать, какая комбинация из ядра, библиотек и пакетов установлена в системе пользователя. Когда пользователь при инсталляции пакета сталкивается с ошибкой отсутствия нужной библиотеки, вы можете посоветовать установить её, однако вы не тестировали это ПО в условиях такой же комбинации зависимостей, как на машине данного пользователя, следовательно и не можете быть уверены, что все будет работать как надо.
Можно также порекомендовать пользователю собрать програму из исходников, но у него может не оказаться подходящих версий компилятора и библиотек. Даже если вы работаете в организации занимающейся стандартизацией данного конкретного дистрибутива, может оказаться что у пользователя устаревшие несовместимые версии библиотек.
Существующие пакетные менеджеры неплохо справляются с поддержкой стабильных версий систем, поскольку они опираются на длительный период разработки и тестирования множеством людей. Однако, когда пользователям необходимо самое свежее обновление програмного обеспечения, скажем по причине найденной ошибки или отсутствия необходимого функционала, они обращаются к тестовым и нестабильным версиям пакетов, которые в свою очередь требуют обновления зависимых пакетов, что ведет к потенциальной нестабильности этих компонентов и всей системы в целом.
Nix внедряет более гибкий подход, позволяющий устанавливать и параллельно использовать разные версии одной и той же программы. Вместо того, чтобы устанавливать программы в системые директории типа /usr, Nix использует отдельные директории для устанавливаемых пакетов в /nix/store. В директории верхнего уровня каждого пакета находится его криптографический хэш, который служит уникальным идентификатором пакета, хранящем информацию о версии и зависимостях. Таким образом разные версии пакета не создают конфликтов между собой и своими зависимостями, так что пользователь в любой момент может произвести строго направленное обновление или отмену обновления компонента.
Начинаем работу с Nix
По иронии судьбы, наилучший способ начать использовать Nix, это обычная сборка из исходников, посредством стандартных комманд ./configure ; make ; make install, выполненых от суперпользователя. Это справедливо для всех систем, включая MacOS X и BSD. Вам понадобится стандартное окружение GNU g++ и установленный curl. Когда установка завершена, Nix в этих инструментах больше не нуждается. Устанавливаемые пакеты и служебная информация хранятся в директории /nix, так что позаботьтесь о наличии достаточного дискового пространства. Если на устройстве, где примонтируется корневая файловая система, недостаточно места, используйте отдельный раздел для /nix, либо используйте возможности bind-mount для монтирования директории /nix на устройство, где имеется свободные 5-50 Гб. Вам так же потребуется добавить путь к usr/local/etc/profile.d/nix.sh в ваш файл bashrc (это установит необходимые для Nix переменные окружения).
Когда Nix собран и установлен, можно начинать устанавливать программы с его помощью. Вы можете получить нужные Nix-пакеты (nixpkgs) скачав их с веб-сайта NIX или подключившись к их Subversion-репозиторию. Однако есть более простой способ, это подписка на канал nixpkg, который создан для автоматического информирования пользователей о новых nix-пакетах:---подробнеее смотрим тут- http://rus-linux.net/lib.php?name=MyLDP/po/nix.html
_________________
Если у тебя нет паранойи,это не значит,что за тобой не следят

jeder

Я читал про это на английском месяца два назад.
Тогда мало что понял, теперь, прочитав на русском понял не больше.

Ну и откуда он будет брать недостающие библиотеки? С инета качать? А если у меня нет инета?
Библиотеки я могу и сам нагуглить и поставить без всяких Никсов, которые непонять чо скачают и поставят, да ещё и место на жёстком жрут.

А ведь вместо того, чтобы изобретать очередной геморой можно просто разработчикам программ включать в комплект с ними все необходимые библиотеки, как это делают виндовозы. И никакой dependency hell не страшен будет.

den

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

jeder

den,

den