Nix - пакетный менеджер для всех дистрибутивов

>Нда... у меня сразу закрались подозрения, что автор юзает Альт, отсюда такой, мягко говоря, легкомысленный подход к пакетному менеджеру.

В альте как раз не забалуешь. APT и точка.

>Так вот -- нормальные дистрибутивы, типа шапки и дебиана, рассматривают себя не как свалку пакетов.

хотя ею являются.

>Хотя все и стараются делать пакеты независимыми друг от друга, реально они кое-где зависят так, как это в зависимостях не прописано (а прописано в policy и подобном)

Это от отчаяния.

>и *такие* зависимости комьюнити дистрибутива тестирует

собственным задом.

>не будет юзать другой пакетный менеджер, написанный хоть на Трижды Православном Божественно Функциональном Супер Языке.

и на десктоп не поставит.

>> Дяденька, сейчас виртуалки это и есть продакшн.

> это для другого.

Я уже один раз спрашивал -- для чего? Для чего и для кого предназначен Nix?

>>и *такие* зависимости комьюнити дистрибутива тестирует

> собственным задом.

мсье знает иные способы тестирования дистрибутивов? не пакетов по отдельности, а именно дистибутивов?

________________________________________

изначально я хотел не флейм разводить, но дело в том, что из-за другого взгляда на роль и надежность дистрибутива (политкорректная формулировка) Альтовцы меня не понимают :-)

Но на девелоперской машинке могут быть уже другие критерии.

>??? Со старого файра на новый апгрейд можна сделать штатными средствами, если новый файр положили в дистр и гарантируют совместимость новой версии со старой. Но назад уже так просто не вернёшся - совместимость старой версии с новой никто не гарантирует.

Замечательно. Проапгрейдили файрфокс аптом - отвалились все экстеншены. Даунгрейдим средствами апта - отвалился вообще.

>Них берёт на себя этот риск, и если что-то сломается то виноват будет них. Не?

никс берет на себя только то, чем управляет. В директории пользователя ему делать нечего.

>Надо исключить всякую возможность конфликтов по разделяемым ресурсам иначе проблем не оберёшся.

И по электричеству тоже. На разные компьютеры и в разные розетки на разных фазах...

>Я тоже винду давно не видел, но всё таки из под юзера там програмы ставить можно, если не на c:\ то на d:\ или в свой каталог.

Ну речь то шла про program files...

>Кажись c:\Program Files\Shared Programs\ для этого. Пусть виндузятники поправят.

а кто кроме самого микрософта и симантека им пользуется?

>В виндовсе тоже есть свой пакетный менеджер. Пакеты называются .msi.

и это не самый плохой вариант.

>В /nix тоже помойка.

с какого боку?

Я уже один раз спрашивал -- для чего? Для чего и для кого предназначен Nix?

уже отвечал. для десктопа.

> Пример по проще - из статтьи. Мы поставили два варианта Firefox - firefox2 и firefox3. Запустили firefox2 - всё хорошо. Запустили firefox3 - профиль сконвертировали в формат firefox3 - всё хорошо. Спасибо ниху - у нас есть возможность запустить firefox2 или даже firefox1.x. Запускаем. Профиль не читается. Почему? Почему них не обработал эту типичную ситуацию?

Да, дистр это не набор пакетов. И такую ситуацию вообще не стоит обрабатывать. Ибо:

Пользователь в ФФ2 зашел на один сайт и запомнил один пароль, а в ФФ3 зашел на другой сайт и запомнил другой пароль. Потом попытался зайти наоборот...

>мсье знает иные способы тестирования дистрибутивов? не пакетов по отдельности, а именно дистибутивов?

Ну так и нечего придумывать про стабильные дистрибутивы. Стабильные дистрибутивы стабильны пока пользуются нестабильными и исправляют ошибки.

>изначально я хотел не флейм разводить, но дело в том, что из-за другого взгляда на роль и надежность дистрибутива (политкорректная формулировка) Альтовцы меня не понимают :-)

ну а я то здесь причем?

>Но на девелоперской машинке могут быть уже другие критерии.

дело не в критериях, дело в гибкости.

> уже отвечал. для десктопа.

Для чьего дескопа?

1) разработчика?

2) продвинутого пользователя?

3) блондинки?

мои ответы:

1) ./configure && ...

2) пусть он лучше тестирует нестабильный дистр, а если надо что-то стабильное -- то из dual boot/виртуалки стабильный дистр -- это надежнее и удобнее

3) нелья ей давать nix

>Пользователь в ФФ2 зашел на один сайт и запомнил один пароль, а в ФФ3 зашел на другой сайт и запомнил другой пароль. Потом попытался зайти наоборот...

пользователь зашел в файрфоксе зашел на один сайт и запомнил один пароль, а в конке зашел на другой сайт и запомнил другой пароль. Потом попытался зайти наоборот...

почему в дистрах лежат и конк и файрфокс одновременно?

> дело не в критериях, дело в гибкости.

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

>1) ./configure && ...

хочу пакетный менеджер.

>2) пусть он лучше тестирует нестабильный дистр, а если надо что-то стабильное -- то из dual boot/виртуалки стабильный дистр -- это надежнее и удобнее

не хочу тестировать. хочу пользоваться свежим софтом, причем в том наборе версий, который мне нужен.

>3) нелья ей давать nix

Это ее дело. Но возможность использовать относительно свежий десктопный софт совсем не лишняя.

>ну хорошо, пусть гибкость будет критерием -- так сойдемся? Только я представить пока не могу, где это будет лучше виртуалки.

нафиг мне виртуалки? Чтобы два гимпа - дае виртуалки? или две dcraw - еще две виртуалки? а еще под файроксы пару?

виртуалка хороша для тестинга, а не для постоянной работы с общими данными.

> почему в дистрах лежат и конк и файрфокс одновременно?

потому что они не юзают один и тот же файл конфигов.

но ФФ2 и ФФ1 под nix (по слухам) юзают один и тот же файл конфигов

openVZ достаточно экономичная виртуалка (даже может и не виртуалка, а контейнеры) -- их можно запускать быстро и дешево (по памяти)

>потому что они не юзают один и тот же файл конфигов.

Ну пароли, получается, не записали.

>но ФФ2 и ФФ1 под nix (по слухам) юзают один и тот же файл конфигов

Они везде используют одни и теже пользовательские конфиги.

я без всякого никса долгое время использовал ff3 и ff2 с одним профилем и ничего, нормально работал.

Не нравится, можно прописать запуск с разными профилями - будут разные конфиги.

Это яастная проблема в пользовательском каталоге. nix, как и все остальные пакетные менеджеры, не смотрит в пользовательские каталог.

>openVZ достаточно экономичная виртуалка (даже может и не виртуалка, а контейнеры) -- их можно запускать быстро и дешево (по памяти)

Зачем? и как они будут работать с одним и тем же монитором одновременно? Как будут копировать из одной вирталки в другую?

Это что, решение для двух гимпов? или файрфоксов?

> не хочу тестировать. хочу пользоваться свежим софтом, причем в том наборе версий, который мне нужен.

Вот такого не бывает -- свежий софт именно теструют, а не пользуются им :-) хотя это может и быть похоже на использование :-)

> и как они будут работать с одним и тем же монитором одновременно?

ммм... хорошо, соглашусь тут с тобой -- openVZ это серверное решение, я не знаю, умеет ли оно видяху виртуализовывать

> Как будут копировать из одной вирталки в другую?

как расшаренное по сети например

> у каждого приложения его профиль лежит в отдельном sandbox'е.

не, не лежит. Похоже, там только wrapper'ы для бинарников : http://nixos.org/releases/nix/nix-0.12/manual/#sec-profiles . Но можно и "eбилды" переписать, чтобы один sandbox -- один профиль с настройками.

>Вот такого не бывает -- свежий софт именно теструют, а не пользуются им :-) хотя это может и быть похоже на использование :-)

да весь музыкальный, видео и графический софт можно использовать только так, поскольку по фичам он только выходит в юзабельное состояние. Это же не tar, bash или coreutils где все уже давно написано.

> хочу пользоваться свежим софтом, причем в том наборе версий, который мне нужен.

Мне это никогда не *надо* было и я не могу представить, чтобы понадобилось, да еще вкупе с добавкой "хочу пакетный менеджер" (это значит, требуемые версии будут еще и быстро-быстро меняться???).

Посему я умолкаю.

> Я уже один раз спрашивал -- для чего? Для чего и для кого предназначен Nix?

Распределённый пакетный менеджер, по аналогии с DVCS. Каждый пакет ставится по умолчанию в отдельный "слот", разные версии всегда ставятся в разные слоты , никакого конфликта версий. Для запуска нужного бинарника/поиска профиля/нужных библиотек используются корректно проставленные симлинки, у каждого пакета свой профиль со своим набором линков (примерно как игрушки под линуксом враппером запускаются). Плюс, потенциально другой, более гибкий набор единиц, по которым определяются зависимые пакеты и метаданных - параметров сборки. Бинарные сборки и из исходников.
0install проповедовал похожую идеологию, ставить всё в разные слоты, адресовать по хешу от контента. Но 0install был расчитан на авторов приложений, что каждый захочет не зависеть от дистростроителя и собирать Klik-подобные пакеты, которые работают везде. А здесь, похоже, ориентация на гентушников-лфсников-ССЗБ-дистростроителей.

>ммм... хорошо, соглашусь тут с тобой -- openVZ это серверное решение, я не знаю, умеет ли оно видяху виртуализовывать

ну на то они и иксы, что можно по сети запустить на основном хосте приложения изо всех остальных виртуалок. Но имхо это не решение ни разу. Не ту оно проблему решает.

>как расшаренное по сети например

я имел в виду, в одной программе выделить, в другую вставить.

>Мне это никогда не *надо* было и я не могу представить, чтобы понадобилось, да еще вкупе с добавкой "хочу пакетный менеджер" (это значит, требуемые версии будут еще и быстро-быстро меняться???).

а мне очень не хватает той простоты, которой отличается установка приложений в макос. Одним щелчком смонтировал образ, директорию в applications перенес и... все.

Причем и mime информация обновляется и все, что хочешь.

Но при этом хочется удобства и мощи пакетного менеджера. Имхо, nix вполне может стать такой золотой серединой.

> мсье знает иные способы тестирования дистрибутивов? не пакетов по отдельности, а именно дистибутивов?

конечно, чужим задом. Допустим, тебе надо протестировать дистрибутив с 1000 пакетов. Берёшь N обезьян-космонавтов (если мало N, возьми K = 1000..1000000), ждёшь, пока они протестируют, считаешь количество недовольных, фиксишь конфликты. Потом бац -- у тебя протестированный дистрибутив.

Как ведёт себя сейчас красноза^H^Hглазая обезьяна-космонавт? Качает, емёржит, натыкается на грабли, лезет в гуголь и багзиллу, выясняет проблемную комбинацию конфигурации-тулчейна-фич-пакетов, качает или пишет патч, переподписывает дайджест, собирает с наложением патчей либо на исходники, либо на ебилд.
Как себя ведёт вторая обезьяна-космонавт с той же проблемой? Опять берёт банан ^W кактус ^W ебилд, гуголь, и тоже самое по новой. Хотя у первой обезьяны в локальном оверлее уже лежит фикс. А обезьяна ленивая, до багзиллы не добежит. Так если параметры сборки вынести в ключик и по этому ключику составить адрес в P2P-подобной сети поиска таких оверлеев-репозиториев, может быть второй обезьяне вообще минимум телодвижений придётся делать, только дождаться пока "вызывающая доверие обезьяна" (читай, с подписанным внушающем доверие, то есть, большинством других обезьян сертификатом-электронной подписью) примет патч в свой репозиторий.

Ну то есть, это картинка не "как есть", а как должно или могло бы быть.

> я имел в виду, в одной программе выделить, в другую вставить.

а чем х-овый буфер обмена не годится?

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

> а мне очень не хватает той простоты, которой отличается установка приложений в макос. Одним щелчком смонтировал образ, директорию в applications перенес и... все.

И там вместе живут приложения разных версий?

(а что касается моего дебиана, там у меня apt-get install и все стоит без проблем)

> но ФФ2 и ФФ1 под nix (по слухам) юзают один и тот же файл конфигов

эта проблема совсем не проблема. Вот в Gentoo например KDE3 и KDE4 запускаются враппером, который делает нужный симлинк ~/.kde то ли на ~/.kde3 то ли на ~/.kde4. В никс есть профили приложения, где стоит симлинк на нужный бинарник, в каждом профиле свой. Нужные конфликтующие библиотеки в разных версиях тоже можно прописать в враппере, в LD_LIBRARY_PATH/LD_PRELOAD, например, как это делают игрушки вроде quake.
Теперь думаем, а что мешает в "ебилде" прописать симлинк не только на бинарник, но и на профиль настроек приложения, перед запуском такого бинарника-враппера. "Профиль приложения" может генерироваться никсом автоматически, значит и ссылка на профиль с настройками тоже.

> а мне очень не хватает той простоты, которой отличается установка приложений в макос. Одним щелчком смонтировал образ, директорию в applications перенес

тоже хорошо выглядит на бумаге. А на деле FAT binaries такие FAT. Если нужно приложение только под x86, то всё равно качаем толстый бинарь папку-бандл со всеми версиями внутри. Интересно, а если вдруг тулчейн изменится в новой версии леопарда, бинарная совместимость поломается и бинарь не запустится? Как там совместимость ABI обеспечивается? А так у нас есть одна версия пакета с исдохниками, есть другая с бинарниками, и по первой можно найти или сгенерировать с нуля вторую (которых может быть несколько, разные параметры среды сборки = разные бинарники)

>>...выбраться из "ада зависимостей" >Just use APT, Luke

Just use YaST/zypper, Luke... :)

Fuck them all, Luke. We have own packet manager, with blackjack and hookers. Use emerge and layman!

>И там вместе живут приложения разных версий?

а то. живут. Куда им деваться?

Хотя мне важнее то, что программу я беру на сайте производителя, а не в некоем отстойнике, который делают совсем другие люди. Могу взять старую, могу новую, могу бету, могу рок стейбл.

>(а что касается моего дебиана, там у меня apt-get install и все стоит без проблем)

при условии, что нужная программа нужной версии есть в репозитарии.

>>Наконец-то можно будет запускать программы без зависимостей. Всегда >>мечтал запустить что-нибудь без пакета kernel, glibc, libgcc и т.д....

> ну положим без глибц ты ещё что-то запустишь (статика), а как будешь > без ядра запускать свой любимый krename? с помощью ntoskrnl.exe?

Пипец, народ, вы юмора не понимаете. Я хотел подъебнуть тех идиотов, которые считают, что зависимости - это зло...

>тоже хорошо выглядит на бумаге. А на деле FAT binaries такие FAT.

а виртуалки не FAT?

>Если нужно приложение только под x86, то всё равно качаем толстый бинарь папку-бандл со всеми версиями внутри.

во многих случаях это меньшее зло. Например, скачаный дистр затем можно ставить на все машины.

>Интересно, а если вдруг тулчейн изменится в новой версии леопарда, бинарная совместимость поломается и бинарь не запустится? Как там совместимость ABI обеспечивается?

а как бинарная совместимость в линуксе обеспечивается? Сколько вариантов, столько и сборок.

>А так у нас есть одна версия пакета с исдохниками, есть другая с бинарниками, и по первой можно найти или сгенерировать с нуля вторую (которых может быть несколько, разные параметры среды сборки = разные бинарники)

Во первых, сборка не всегда проходит успешно. Во вторых, это хорошо, но далеко не всегда нужно. Собственно, nix поддерживает сборку.

AVL2, я думаю тут решить может только твой опыт. Мои опасения: прыгание из версии в версию, бегая от багов, сведут на нет скорость и удобство работы. Если это будет не так, интересно прочитать как оно получается.

Я думаю, nix не заменит системный менеджер пакетов. Ребята сделали уже дистрибутив, в котором весь софт ставится через nix, но мне это не кажется хорошей идеей. basesystem вполне может быть в одном экземпляре, грубо говоря, как хост-система, поскольку это надежно и просто, а функционал давно уже в общем и целом наработан.

А вот часть сугубо пользовательских программ вполне может ставиться и сопровождаться никсом. Файрфокс, пиджин, гимп, опенофис и т.д.

Здесь все таки версии выходят чаще чем дистрибутивы и хотелось бы с удобством ставить, обновлять и сносить именно те или иные версии производителя.

А так согласен, только опыт и развитие сторонних репозитариев с софтом покажет, насколько оно работоспособно.

первая мысль - велосипед.

сходил по ссылке - теперь моя хотеть.

>Я думаю, nix не заменит системный менеджер пакетов. Ребята сделали уже дистрибутив, в котором весь софт ставится через nix, но мне это не кажется хорошей идеей. basesystem вполне может быть в одном экземпляре, грубо говоря, как хост-система, поскольку это надежно и просто, а функционал давно уже в общем и целом наработан.

похоже что держать весь дистр на этой системе слишком накладно, да и не на столько нужно, а для "поставить глянуть как там кде 4 и вернутся на 3" очень подходит.

Действительно, stdenv (версии gcc, glibc и т.д.) в NixPkgs менять хочется пореже. Так и случается.

У нас в NixOS есть current-system - и это нормально, если она в одном экземпляре. Но при любом upgrade очень приятно иметь две системы - новую и старую. С переиспользованием пакетов, которые в них одинаковы. За это Вы получаете два бонуса.

Во-первых, атомарность upgrade (то есть один вызов kill -9 из-под root не позволяет оставить в систему в состоянии, из которого надо её выковыривать). И в yum, и в apt я сталкивался с ситуацией, когда при неправильном наборе репозиториев утилита настойчиво предлагает снести (но не обновить) пол-системы. Успешное "yum install man" мне однажды убило yum до незапускаемости. Так что я лучше попользуюсь Nix у себя на ноутбуке, где волен выбирать что угодно.

Ну и, во-вторых, возможность откатить любые изменения, кроме, возможно, настроек GRUB и подключения разделов.

Хотя для разработки уже сама лёгкость установки нескольких наборов версий и переключения между ними весьма приятна.

Расскажу немного о своем опыте использования nix/nixos.

В течение нескольких лет пользовался разными дистрибутивами (redhat, debian, gentoo, archlinux). В каждом из них что-то не устраивало, приходилось создавать выражения для сборки своих пакетов (./configure && make && make install удобно использовать лишь в простых случаях, потом замучаешься чистить мусор). В каждом из этих дистрибутивов иногда что-то ломалось в результате обновлений, откат при этом сложно назвать тривиальным и простым (в некоторых дистрибутивах приложения при обновлении меняют и свои конфиги). Было много других проблем/недостатков, сейчас описывать все не буду...

В nix в функциональном стиле можно описать пакет и необходимые зависимости для его сборки. Пакет ставится по уникальному адресу /nix/store/<hash>-<имя пакета>, hash формируется из комбинации всех источников (контрольная сумма исходных текстов программы, версия компилятора, все необходимые программы и библиотеки, набор патчей, выражение для сборки). При изменении любой исходной компоненты собирается новый пакет с другим уникальных хэшем (и это правильно, формально это уже другая программа). Можно одновременно иметь нужное количество разных версий одного пакета, атомарные обновления позволяют не бояться замены текущих библиотек на новые версии с последующим болезненным откатом. Если обновление прошло неудачно (например, нужные программы перестали работать), можно одной командой откатиться на любую предыдущую сохраненную конфигурацию (ненужные можно удалять).

Первое время использовал nix на некоторых серверах (debian) и на десктопе (archlinux) для замены некоторых программ на нужные мне версии. Потом начал эксперименты с NIXOS (весь дистрибутив в функциональном стиле). В NIXOS все настройки описываются в виде выражений, все конфиги тоже находятся под контролем nix. Это позволяет в любой системе контроля версий поддерживать выражения для сборки системы, автоматически собирать уникальный дистрибутив для нужного компьютера с уже настроенными и поддерживаемыми конфигами.

В классических дистрибутивах конфиги, отлаженные в течение нескольких лет, потом почти не меняются. Но при выходе машины из строя придется поставить дистрибутив с нуля, обновить его, вспомнить какие специфические пакеты нужно поставить, какие конфиги поменять, какие ненужные пакеты/сервисы удалить. Понятно, что можно делать бэкапы конфигов/всех разделов, но кто это делает всегда в полном объеме? Легко можно забыть скопировать какой-то конфиг и это будет уже другая система... В NIXOS я создаю загрузочный CD с конфигурацией сервера (включая все нужные для него пакеты и конфиги), разбиваю новый диск на разделы (скриптом, в нем создаются таблица разделов, RAID, LVM, форматируются разделы и т.д.), затем с помощью одной (!) команды (nixos-install) ставлю всю настроенную ранее систему, перезагружаюсь - у меня уже настроенный сервер, осталось только переписать на него данные (ключи, базы данных) со старых серверов или из бэкапов.

Продолжение предыдущего сообщения...

Все системы я собираю на сборочном сервере, делаю бинарные обновления, которые копируются и устанавливаются на целевых машинах. При этом на целевой машине не надо иметь компилятор и утилиты для сборки, на ней только минимальный необходимый функционал (мечта security специалиста), при неудачном обновлении можно откатить всю систему на старую версию даже в случае зависания системы. Например, при переезде с upstart на runit не стал запускаться init, проблема решилась просто перезагрузкой и выбором в меню grub предыдущей версии (и последующим обновлением до рабочего состояния runit).

Писать можно много про преимущества, есть конечно и недостатки: дистрибутив довольно молодой, не всегда согласишься с изменениями пакетов разработчиками nix (впрочем, как и в других дистрибутивах). В данный момент создал свои ветки разработки в Mercurial для nix, nixos, services, configs. Иногда синхронизирую пакеты с основной веткой, но многие изменения использую локально. Например, перевел систему с показавшегося мне нестабильным upstart на runit. Теперь все сервисы NIXOS находятся под управлением runit, получаем supervising, логирование всех сообщений сервиса, реализовал учет зависимостей сервисов.

P.S. Это сообщение отправлено с моего десктопа на NIXOS, все

>У нас в NixOS есть current-system - и это нормально, если она в одном экземпляре. Но при любом upgrade очень приятно иметь две системы - новую и старую. С переиспользованием пакетов, которые в них одинаковы.

Согласен, это полезно.

>Во-первых, атомарность upgrade (то есть один вызов kill -9 из-под root не позволяет оставить в систему в состоянии, из которого надо её выковыривать). И в yum, и в apt я сталкивался с ситуацией, когда при неправильном наборе репозиториев утилита настойчиво предлагает снести (но не обновить) пол-системы.

да и при правильном наборе репозитариев такое возможно. Мало ли чего там в зависимостях накосячат или у апта алгоритм разрешения зависимостей придумает...

>Ну и, во-вторых, возможность откатить любые изменения, кроме, возможно, настроек GRUB и подключения разделов.

тоже хорошо.

>Хотя для разработки уже сама лёгкость установки нескольких наборов версий и переключения между ними весьма приятна.

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

>В NIXOS я создаю загрузочный CD с конфигурацией сервера (включая все нужные для него пакеты и конфиги), разбиваю новый диск на разделы (скриптом, в нем создаются таблица разделов, RAID, LVM, форматируются разделы и т.д.), затем с помощью одной (!) команды (nixos-install) ставлю всю настроенную ранее систему, перезагружаюсь - у меня уже настроенный сервер, осталось только переписать на него данные (ключи, базы данных) со старых серверов или из бэкапов.

не понял, но ведь большинство конфигов правится уже после установки и изменяется так или иначе на протяжении всего жизненного цикла этой инсталляции . Каким образом изменения в конфигах отражаются в инсталляционных скриптах, которые делались гораздо раньше?

> не понял, но ведь большинство конфигов правится уже после установки и изменяется так или иначе на протяжении всего жизненного цикла этой инсталляции . Каким образом изменения в конфигах отражаются в инсталляционных скриптах, которые делались гораздо раньше?

Все конфиги всегда правятся только в репозитории. На самом сервере конфиги вручную не правятся никогда в такой политике. Ведь любое изменение конфига - изменение конфигурации всего сервера. Надо изменить конфиг - правим его (или набор выражений, еще в конфигах можно использовать подстановки @имя@, чтобы облегчить изменение и дублирование каких-то параметров, IP например), командуем собрать и установить обновление. При обновлении перезапустится только нужный нам сервис, так как его хэш изменился из-за нового конфига.

Как таковых специальных инсталляционных скриптов нет, ведь все конфиги лежат в общем хранилище и сервисы используют их (sshd -f /nix/store/<hash>-ssh-config). А при установке нового сервера собираем ISO из текущих выражений и прожигаем ее на болванку. Получается текущая версия сервера для автономной установки. Все текущие изменения уже на ней. А будущие будут приходить с обновлениями. При переустановке просто обновится текущая версия установочного диска. На диске настроен dhcp-клиент и ssh, поэтому можно просто вставить диск в новый сервер и спокойно по сети выполнить всю установку в автоматическом режиме. А можно и автономно без сети, с консоли...

Это вариант, но мне больше по душе конфиги в svn. Поправил на сервере, оттестировал, если надо и коммит.

Сохраняется история изменений. Полное понимание процесса.

Если подумать, то наверное можно объединить оба этих способа.

Насчёт несогласия с изменениями - fork пакета внутри офциального репозтория становится делать всё проще и проще (что и наблюдаем, не всегда по делу). Про runit - пришлите, пожалуйста, патчи на nix-dev.

Кстати, Вы бываете в #nixos?

MichaelRaskin

Ну не знаю, у меня конфигурация делится на открытую часть (для простоты commit в публичный репозиторий, чтобы можно было говорить "а как у меня не работает?") и закрытую - hostname, пароли, которые просто импортируются открытой частью и которые меняются только в сторону разрастания. А потом rebuild.

По определению - если такое возможно, то либо apt неправильный, либо репозиторий, либо набор репозиториев несочитаем. Я готов принять часть ответственности на себя и последний пункт, так как мне не нравится сама возможность ситуации.

Если для тестов собирать пакет через nix-build под NixOS, то всё будет чисто и воспроизводимо. Есть ещё chroot builds - у них чистота, кажется, строго не ниже, чем у Вашего метода. Настройки иногда сбрасываю запуском под "пустым" пользователем - всяко экономнее VM.