Вышел NixOS 14.04

Данный дистрибутив основан на «чисто функциональном пакетном менеджере Nix».

Да уж, дистрибутивы уже на пакетных менеджерах основываются

/nix/store/r8vvq9kq18pz08v249h8my6r9vs7s0n3-firefox-2.0.0.1/

Наркоманы и долбанутый PATH

nix-shell proj.nix - кидает в баш с настроенным окружением

nix-build proj.nix - собирает пакет

все экспорты и прочее приписываются за тебя, вообще об этом думать не надо даже :)

Пакеты собираются так, чтобы искать конфиги не в $prefix/etc/, а в /etc.

А не смущает тот факт, что это отравляет саму изначальную идею сайд-бай-сайд установки многих версий? То есть то, что они будут конфликтовать по файлам вне пределов /nix/. Есть конечно, сложные случаи, когда это практически оправдано, например, когда нужно установить правила для udev или службу для dbus, и это приходится выносить в настоящий корень, но уж фонтконфиги-то прекрасно живут каждый со своим /etc и каждый со своим кэшем.

Вот и весь рокет саенс. А воспроизводимый билд на готовой инфраструктуре, когда всё что надо куда надо закоммичено тоже нетяжело выглядит --- mock --rebuild *.src.rpm, так что непонятно, в чём здесь состоит преимущество.

Дьявол в деталях. Я с mock поверхностно знаком, но подозреваю, что если тебе захочется собрать свой проект, с зависимостью на Boost собранный с хитрым флагом, то тебе придется лепить отдельный src.rpm и публиковать его в реп, а в Nix указываешь (untested):

buildInputs = [ (pkgs.boost.override { configureFlags = "..." }) ];

И дело в шляпе. Это в худшем случае надо руками задавать configureFlags, обычно там уже есть опция (аналог USE флагов в генту), которую надо просто включить/выключить.

Кроме того Nix относится к пакетам, как Make относится к таргетам. Если он видит, что ребилдить не надо, то оно и не будет, т.к. результат сборки строго детерминирован, то в Nix такая оптимизация возможна, а в RPM/DEB нет.

Дьявол в деталях. Я с mock поверхностно знаком, но подозреваю, что если тебе захочется собрать свой проект, с зависимостью на Boost собранный с хитрым флагом, то тебе придется лепить отдельный src.rpm и публиковать его в реп, а в Nix указываешь (untested):

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

Кроме того Nix относится к пакетам, как Make относится к таргетам. Если он видит, что ребилдить не надо, то оно и не будет, т.к. результат сборки строго детерминирован, то в Nix такая оптимизация возможна, а в RPM/DEB нет.

А вот это, конечно, очень круто.

/nix/store/r8vvq9kq18pz08v249h8my6r9vs7s0n3-firefox-2.0.0.1/

Почему не наоборот, почему не /nix/store/firefox-2.0.0.1-8vvq9kq18pz08v249h8my6r9vs7s0n3 ?

Так было бы гораздо удобней

Э, нет, достаточно, чтобы этот буст выплыл выше по приоритетам (или, например, бампнуть ему версию). В крайнем случае, можно сделать ручку для сборки и переключать опцией src.rpm, передавая её mock.

будет выглядить

Проверено: Shaman007
орфографическая олигофрения процветает.