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

> "nix" в разговорном немецком обозначает что-то вроде русского "нихрена"

филолог, блин http://en.wikipedia.org/wiki/Nix

http://en.wikipedia.org/wiki/Nyx_(mythology)

> Зачем такое делать? Чтобы специально создать себе проблемы?

тестинг например нестабильного девелоперского + ОДНОВРЕМЕННО стабильного незамаскированного.

> Естественно, какой же это стейбл, если к нему сторонние репо подключить?

что, apt-get так не могёт? stable+unstable одновременно?

> и поэтому в макос программа для редактирования хоткеев весит 20 мб?

FAT binaries такие FAT

>А в дебиане с этим проблем нет, просто ставишь прошлую версию и все
Верно. Но как мне поставить новый gimp в debian? Пере собрать GNOME?
NIX - нужен.

> Во всех дистрах применяют все три варианта. И везде свои очевидные минусы. nix позволяет решить эту проблему, причем на стадии установки бинарного пакета.

И очевидных минусов такого подхода вы не видите? dll-hell вас ничему не научил? Вы уверены, что две разных версии одной библиотеки уживутся вместе?

Включите в мозгу третий компонент - который используется и X-ом и Y-ком, назвём его F, который также использует библиотеку ZZZ. Какую версию библиотеки он должен использовать для комуникации с X и Y одновременно? Первую, вторую, по рандому?

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

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

У меня такой проблемы нет. Если мне будет надо я себе в любой каталог любую программу любой версии с любыми зависимостями накомпилирую. Это возможно актуально для любителей посидеть на "кровавом поносе", потому что в стабильных дистрибутивах обновления ничего не ломают и неплохо выручают бэкпорты.

> типа, /usr/bin/firefox у них у всех одинаковый.
> Так что пересекуться по файлам.

А обозвать /usr/bin/firefox2 и /usr/bin/firefox3 мама не позволяет?
Опять же проблема выеденного яйца не стоит. Поверьте, я не против сабжа, не призываю его "закопать", или ещё как-то там поступить. Не называю его "лисапедиком". Он найдёт своё применение. Но утверждать, что это -- всеобщее благо и весь софт за пределами базовой системы теперь нужно обязательно ставить именно так... кхм, с этим лучше к Алкснису.

> Как бы было хорошо если бы эти новые иксы поставились в отдельный "слот" и мне бы пришлось бы только удалить новую версию.

да, или надо переделывать неслотовый ебилд в слотовый. Или в апстриме что-то изменится, и потребуется пересборка (сделали из неслотового слотовый => изменение ебилда и подписи => изменение дерева зависимостей => включилась пересборка/дегрейд если что-то замаскировано).
Вместо demerge можно было наверное попробовать откатить по одному новые версии, замаскировать, и накатить по одному в нужном порядке. Собирать тем же компилятором, тем же тулчейном. Но это надо было угадать нужную последовательность установки пакетов.

> виртуалка - не решение. Речь идет не об отладке, а о продакшене.

Дяденька, сейчас виртуалки это и есть продакшн. На голое железо ставится базовая ОС в минимальной конфигурации, на которую логинится админ и поднимает виртуализатор (OpenVZ, VServer) и несколько VM. Затраты на железо меньше в два-три раза. Затраты на администрирование - меньше на порядок.

> Вы уверены, что две разных версии одной библиотеки уживутся вместе?

уверены. Они стоят в разных "слотах" /бранчах DVCS/ сэндбоксах и друг другу не мешают. Зависимости каждого приложения от нужной версии библиотеки явно прописаны в профиле этого приложения. То же самое, что делать ручками с ./configure --prefix=.. && run.sh с нужным LD_PRELOAD, только автоматизированно, централизованно.

> Включите в мозгу третий компонент - который используется и X-ом и Y-ком, назвём его F, который также использует библиотеку ZZZ. Какую версию библиотеки он должен использовать для комуникации с X и Y одновременно? Первую, вторую, по рандому?

ту любую, совместимость с которой не поломана. А то, что "неполомана", может явно храниться в дистрибутиве. Просто обычные дистрибутивы обычно допускают одну такую ветку (аналогия с SVN) или слоты -- несколько веток (branch в SVN), а тут получается что-то вроде DVCS, каждый "стабильный" набор библиотек идёт в отдельную "авторскую" ветку.

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

Возьмём Генту с портеджем и проблемами в нём. Если такая проблема уже присутствует, разгребать её придётся каждому пользователю вручную. А тут можно подписать такие стабильные зависимости цифровой подписью "дистростроителя" (автора в DVCS), и по ним вытянуть стабильный набор параметров, сопоставить со своим, разрешить конфликты полуавтоматически.

>Тогда, к примеру, две (или более) версии минорно отличающихся друг от друга библиотек будут одновременно загружены.

это будет трындец с безопасностью если вместо обновления одной либы прийдется обновлять все пакеты в которых она используется. кол-во обновление возрастят на порядки

> аналогично в федоре.

> поставил greystoration из ***девелопмента***, он обновил gimplib. Гимп теперь не запускается ибо требует более нового гтк. поставить новый гимп уже не могу, поскольку обновляется вся система по зависимостям и десяток связей провисает. приехали.

ИМХО, Федора тут ни при чём.

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

>Если мне будет надо я себе в любой каталог любую программу любой версии с любыми зависимостями накомпилирую.

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

а тут просто берешь готовый, собраный пакет и ставишь. точка.

>А обозвать /usr/bin/firefox2 и /usr/bin/firefox3 мама не позволяет?

пакет уже собран в виде rpm. и ожидает увидеть либы не где нибудь а в /usr/lib и файлы у него /usr/bin/firefox

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

это просто-напросто следующее поколение после апта. Кому-то и апт до сих пор не нужен.

> "nix" в разговорном немецком обозначает что-то вроде русского "нихрена"

Или, более литературно, nix -> nichts = ничего :)

> > Включите в мозгу третий компонент - который используется и X-ом и Y-ком, назвём его F, который также использует библиотеку ZZZ. Какую версию библиотеки он должен использовать для комуникации с X и Y одновременно? Первую, вторую, по рандому?

> ту любую

По рандому, значит. И получит рандомный результат.

К примеру, если я обновил драйвер в ядре, и теперь мне надо обновить userspace либы, то них волшебным образом сделает возможным оставаться на старых либах? А новые либы тащить только к новым програмам?

> А то, что "неполомана", может явно храниться в дистрибутиве.

А них тогда нах?

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

На paco не смотрел? paco.sf.net

> > "nix" в разговорном немецком обозначает что-то вроде русского "нихрена"

> филолог, блин http://en.wikipedia.org/wiki/Nix

Любопытный ты товарищ. Тебе говорят "в немецком", а ты ищещь в английской вики.

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

>На paco не смотрел? paco.sf.net

сейчас глянул, интересный. но свой дороже %-)

>ИМХО, Федора тут ни при чём.

федора здесь притом, что вообще-то нечего было давать обновлять gimplib, раз он требует новый gtk.

Во вторых, я не виновных ищу, а хочу иметь возможность ставить отдельно взятый свежий софт не ломая систему.

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

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

>Затраты на администрирование - меньше на порядок.

да, вместо одной системы надо обновить десяток vm -> затраты на администрирование на порядок меньше.

> На paco не смотрел? paco.sf.net

Любопытный changelog

2.0.0 [6 Jun 2007]
^^^^^^^^^^^^^^^^^^
Both paco and gpaco have been rewritten in C++.

...

2.0.3 [17 Jul 2007]
^^^^^^^^^^^^^^^^^^^
+ Rewritten libpaco-log in C.

Потихоньку человек начинает понимать что к чему :))

> По рандому, значит. И получит рандомный результат.

не совсем "по рандому". Вот есть у тебя граф зависимостей. Ищем один путь по пакетам -- получаем стабильные, "не поломанные" зависимости. Ищем несколько путей по "используемым фичам", которые характеризуют любой не поломанный пакет -- получаем тоже "не поломанные" зависимости. Речь о том, что гранулярность можно сделать тоньше, чем пакет. Например, старый+патч вместо нового = одна и та же метка "стабильности" в графе.

> К примеру, если я обновил драйвер в ядре, и теперь мне надо обновить userspace либы, то них волшебным образом сделает возможным оставаться на старых либах? А новые либы тащить только к новым програмам?

вот это уже интереснее. Если сменилось ядро+драйвер, или тулчейн, мы получаем бинарник, зависящий от тулчейна и ядра (или только ядра, если совместимость с тулчейном не поломана). В обычном пакетном менеджере мы не можем получить два бинарника, переключаться надо вручную. Или пересобирать, чтобы остался только один бинарник. Здесь же, если "совместимость не поломана", гипотетически можно не пересобирать, если зависимости указаны достаточно точно. То есть, если раньше такую тонкую зависимость (меньше целого пакета) нельзя было указать вообще, то теперь -- можно.

> А них тогда нах?

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

>Вы уверены, что две разных версии одной библиотеки уживутся вместе?

да, ведь они грантированно лежать в разных каталогах.

>Включите в мозгу третий компонент - который используется и X-ом и Y-ком, назвём его F

Компоненты моего мозга либами не пользуются.

> , который также использует библиотеку ZZZ. Какую версию библиотеки он должен использовать для комуникации с X и Y одновременно? Первую, вторую, по рандому?

X и Y всегда используют свои версии библиотеки ZZZ

Если одна из версий этой библиотеки совместима по вызовам с другой (например ZZZ1), программу F помжно собрать с этой версией

F -> ZZZ1 X -> ZZZ1 Y -> ZZZ2

Если же версии не совместимы, значит fail. программу F не соберешь, пока все три программы не будут собраны с одной версией библиотеки.

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

в рамках дистрибутива нужно стремиться минимизировать количество версий библиотек. Но тем не менее во всех дистрах есть несколько версий libdb4, несколько версий glibc и т.д.

> >Затраты на администрирование - меньше на порядок.

> да, вместо одной системы надо обновить десяток vm -> затраты на администрирование на порядок меньше.

Одна система никак не получится. А обновлять VM-ы не обязательно. Сейчас вот у меня создание новой VM с нуля занимает (смотрел в Hudson-е) 2 минуты 40 секунд. Это просто yum install metapackage-with-all-dependencies (плюс немного чёрной маги и с хардлинками для ускорения и сокращения, мы используем VServer, так что нам можна). Создание архитектуры для zero-conf-а позволяет не заморачиватся с конфигурацией. Просто поставил и просто запустил, как обычную програму (фактически, что VM, что програма - один хрен).

них не нужен.

> в отдельные директории в дереве /nix/store.

Где-то я уже такое видел. По-моему в факе LFS. Только называлось по-другому.

> > К примеру, если я обновил драйвер в ядре, и теперь мне надо обновить userspace либы, то них волшебным образом сделает возможным оставаться на старых либах? А новые либы тащить только к новым програмам?

> вот это уже интереснее. Если сменилось ядро+драйвер, или тулчейн, мы получаем бинарник, зависящий от тулчейна и ядра (или только ядра, если совместимость с тулчейном не поломана). В обычном пакетном менеджере мы не можем получить два бинарника, переключаться надо вручную. Или пересобирать, чтобы остался только один бинарник. Здесь же, если "совместимость не поломана", гипотетически можно не пересобирать, если зависимости указаны достаточно точно. То есть, если раньше такую тонкую зависимость (меньше целого пакета) нельзя было указать вообще, то теперь -- можно.

Неужели все забыли что такое dll-hell? Напоминаю, это когда програма А одна работает нормально, програма Б одна работает нормально, а А и Б вместе не работают так как они используют разные версии одной библиотеки. Причём варианты когда програм было всего две и можно было легко вычислить причину встречались редко. Как правило были варианты типа что их 9-ти необходимых програм вместе можно было установить только любые 8-м.

Вот я задал простую задачку, а уже начинаются сложные рассуждения, намного сложнее самой задачи, где-то O(n^2). Что будем делать, когда пакетов, библиотек, драйверов, портов, файлов и других разделяемых ресурсов будет значительно больше? Будем создавать /nix/tmp, /nix/proc, /dev/nix/net, etc?

> > А них тогда нах?

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

А зачем? Added value можеш посчитать? Мы будем в плюсах, по результатам, или в минусах и в каких случаях?

На серваках мне дешевле иметь непротиречивую систему.

> да, ведь они грантированно лежать в разных каталогах.

А зачем? У разных версий даже одной библиотеки разные названия. Они и так не пересекутся.

> > , который также использует библиотеку ZZZ. Какую версию библиотеки он должен использовать для комуникации с X и Y одновременно? Первую, вторую, по рандому?

> X и Y всегда используют свои версии библиотеки ZZZ

> Если одна из версий этой библиотеки совместима по вызовам с другой (например ZZZ1), программу F помжно собрать с этой версией

> F -> ZZZ1 X -> ZZZ1 Y -> ZZZ2

Пример. Компонент F, который используется X-ом и Y-ком - это база данных на диске. ZZZ - libdb. Смогут ли X и Y совместо использовать одну БД если напр. алгоритм создания новых записей у них теперь немного отличается? Алгоритм сломан только для новых записей, то есть чтение старых записей идёт на ура и на первый взгляд всё отлично.

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

> в рамках дистрибутива нужно стремиться минимизировать количество версий библиотек. Но тем не менее во всех дистрах есть несколько версий libdb4, несколько версий glibc и т.д.

А посмотреть внимательно сколько труда вложено в некоторые библиотеки чтобы гарантировать не конфликтность нигде?

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

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

> а тут просто берешь готовый, собраный пакет и ставишь. точка.

Ляяяяя... Его, этот пакет, кто-то должен собрать. Так вот этот человек -- я. Точка.

>А зачем? У разных версий даже одной библиотеки разные названия. Они и так не пересекутся.

сонеймы - да и только, девелоперский линк и хидеры уже нет.

а nix умеет работать с любыми пакетами, пусть они трижды с одинаковыми файлами.

>Пример. Компонент F, который используется X-ом и Y-ком - это база данных на диске. ZZZ - libdb. Смогут ли X и Y совместо использовать одну БД если напр. алгоритм создания новых записей у них теперь немного отличается?

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

>А посмотреть внимательно сколько труда вложено в некоторые библиотеки чтобы гарантировать не конфликтность нигде?

мысль не понял.

То, nix не серебряная пуля. Это даже не обязательно замена системному пакет-менеджеру. Он просто позволяет сделать общий репозиторий для программ под линукс и ставить их на широкий круг дистров.

>К чему ты это всё написал?

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

>Ляяяяя... Его, этот пакет, кто-то должен собрать. Так вот этот человек -- я. Точка.

ну тогда тебе lfs в руки и ничего больше и не нужно.

> типа, /usr/bin/firefox у них у всех одинаковый.

> Так что пересекуться по файлам.

firefox это симлинк, а exe'шник firefox-2.x.x firefox-3.y.z и firefox-config в гномовском стиле, который меняет симлинк и говорит разным конфигурационным скриптам при компиляции плагинов, например, где брать хедеры и библиотеки

>Одна система никак не получится.

получится. c nix - получится.

>А обновлять VM-ы не обязательно.

так одну систему тем более тогда обновлять нет нужды.

>Сейчас вот у меня создание новой VM с нуля занимает (смотрел в Hudson-е) 2 минуты 40 секунд.

угу, данные ты тоже в vm копируешь? как ты собрался из разных vm к одним рабочим столом пользоваться? Через nfs?

> к тому, что это много ручного труда, который вполне можно автоматизировать.
> ну тогда тебе lfs в руки и ничего больше и не нужно.

Зачем преувеличивать настолько. Ты же сам приводил пример только с одной библиотекой по зависимостям. Или в /programs/name будет целиком всё, начиная с glibc?

>firefox это симлинк, а exe'шник firefox-2.x.x firefox-3.y.z и firefox-config в гномовском стиле, который меняет симлинк и говорит разным конфигурационным скриптам при компиляции плагинов, например, где брать хедеры и библиотеки

1) ну если на то дело пошло, экзешники в линуксе только моно делает. А исполняемые скрипты файрфокса имеют одно и тоже имя и точно также, как в никсе, разложены по разным каталогам вида /usr/lib/firefox-version, только сделано это ручками майнтейнера.

А вот ява x86_64 и i386 лежит в одном и том же каталоге вида /usr/java/jre-version и поставить их рядом уже не получится. Только ручками.

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

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

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

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

Оттуда же он и обновляется.

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

>Или в /programs/name будет целиком всё, начиная с glibc?

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

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

Если программа собранапод старый glibc - придется поставить все, включая старый glibc.

По-моему, новость про Nix уже была, нет?

1) Ада зависимостей не существует.
2) Ад порождает как раз вот это недоподелие.

> >Пример. Компонент F, который используется X-ом и Y-ком - это база данных на диске. ZZZ - libdb. Смогут ли X и Y совместо использовать одну БД если напр. алгоритм создания новых записей у них теперь немного отличается?

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

Откуда ясно?!!! Например X может и читать и писать в базу, а Y - только читать. В этом случае версия библиотеки для X должна быть <= версии библиотеки для Y. И не всегда надо обновлятся. Но например библиотека может детектить оборваную транзакцию и автоматически её откатывать, в таком случае всё может работать хорошо до первого (или не первого) сбоя питания когда Y запустится раньше чем X.

С каждым таким вариантом надо внимательно разбиратся. Них такое умеет?

> мысль не понял.

Оно и видно.

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

> То, nix не серебряная пуля. Это даже не обязательно замена системному пакет-менеджеру. Он просто позволяет сделать общий репозиторий для программ под линукс и ставить их на широкий круг дистров.

C:\Program Files\ , не?

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

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

Бардак не надо разводить - и проблем не будет. Я, кстати, и с DLL Hell в винде не сталкивался ни разу - вероятно, потому, что не имею привычки ставить все подряд...

>С каждым таким вариантом надо внимательно разбиратся. Них такое умеет?

нет. Это вообще не входит в обязанности пакет-менеджера.

Или апт так умеет?

>Почему них не обработал эту типичную ситуацию?

сделали тоже самое через апт. Поставили файрфокс, снесли, поставили новый факрфокс, снесли, поставили старый файрфокс.

профиль не читается. апт/yum подвел?

Или просто надо было запускать их с разными профилями?

>C:\Program Files\ , не?

нет.

1) В program files ставит администратор, в никсе может ставить пользователь.

2) В program files (почти) нет shared компонент. В nix либы идут отдельно и ставятся по зависимостям.

3) В program files помойка, а никс - пакетный менеджер.

> >А обновлять VM-ы не обязательно.

> так одну систему тем более тогда обновлять нет нужды.

Есть. Я не могу одной командой создать новый апаратный ящик. Виртуальный почему-то могу а железный почему-то нет. Может них поможет? :-)

> угу, данные ты тоже в vm копируешь?

Как когда, смотря какие даные.

> как ты собрался из разных vm к одним рабочим столом пользоваться?

Это серваки, между прочим. Но проблем не особо - если надо, пользуюсь. :-/ Какие-то проблемы? Дать ссылку на туториал?

> Через nfs?

Я другие сетевые файловые системы люблю, более подходящие к конкретному случаю. Хотя можно и через nfs.

> сделали тоже самое через апт. Поставили файрфокс, снесли, поставили новый факрфокс, снесли, поставили старый файрфокс.

> профиль не читается. апт/yum подвел?

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

Все действия ты должен будешь предпринимать на свой страх и риск. И если что-то сломается то виноват будеш ты и только ты.

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

> Или просто надо было запускать их с разными профилями?

Ну да. /nix/$HOME/, /nix/tmp, /nix/dev, /nix/proc, /nix/lib, /nix/etc, /nix/boot/kernel, ... Надо исключить всякую возможность конфликтов по разделяемым ресурсам иначе проблем не оберёшся. Лучше всего с этим справляется виртуальная машина. Создал виртуалку - и никаких конфликтов.

> 1) В program files ставит администратор, в никсе может ставить пользователь.

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

> 2) В program files (почти) нет shared компонент. В nix либы идут отдельно и ставятся по зависимостям.

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

> 3) В program files помойка, а никс - пакетный менеджер.

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

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

А зачем тогда них? Чтобы ставить тухлый софт? Это извращает идею.

> Если программа собранапод старый glibc - придется поставить все, включая старый glibc.

Чем это отличается от виртуалки? В VServer-е например можно использовать хардлинки для экономии места. Тоесть можно тупо залинкать практически всю систему в отдельный каталог, запустить его как виртуалку, накатать туда новый софт, и безопасно пользоваться. Них такое умеет?

Них умеет обрабатывать post/pre(un)install скрипты?

> Неужели все забыли что такое dll-hell? Напоминаю, это когда програма А одна работает нормально, програма Б одна работает нормально, а А и Б вместе не работают так как они используют разные версии одной библиотеки

ну и откуда возьмётся dll hell в такой задаче в таком пакетном менеджере? "разные версии одной библиотеки" = разные хеши пакетов = разные слоты = эти версии можно будет поставить side-by-side

> А зачем? Added value можеш посчитать? Мы будем в плюсах, по результатам, или в минусах и в каких случаях?

ну мне этот способ видится как вариант для альтернативных ОСей, для облегчения портирования. Где нет родного Xen/VmWare, а только унылый QEMU, например. Берём порт линукс-приложения, делаем ветку в git/hg, получаем уникальный хеш ветки. Потом пишем порт, подписываем пакет в "дистрибутиве" этим хешем. Итого, связали порт и оригинал.
Или вот та же красноглазая гента, где баги непофикшенные резвятся в отдельных частях портеджа, потому что руки у кого-то не дошли. Потому что централизованная база портеджа, и обновления вносить надо централизованно. А пакетный менеджер, скрещенный с DVCS мог бы это дело сильно упростить. Каждый фиксит в своём оверлее, а потом пофикшенное, стабильно работающее вместе автоматически собирается в "основную" ветку (в DVCS. по есть получает подпись/тег в DVCS).

> А зачем? У разных версий даже одной библиотеки разные названия. Они и так не пересекутся.

кроме случая как в генту USE=+a -b emerge lib ... и USE=-a +b emerge lib -- soname одинаковый, названия одинаковые, "набор фич" разный. Или gcc-config 2 .. emerge ... и gcc-config 3 .. emerge (ABI в новом тулчейне может быть другой). Или "собрали новое ядро, пересобрали драйвера и иксы".


> Пример. Компонент F, который используется X-ом и Y-ком - это база данных на диске. ZZZ - libdb. Смогут ли X и Y совместо использовать одну БД если напр. алгоритм создания новых записей у них теперь немного отличается? Алгоритм сломан только для новых записей, то есть чтение старых записей идёт на ура и на первый взгляд всё отлично.

не должны они использовать "одну БД" в таком случае. одна БД у Х должна быть в сэндбоксе Х, другая у У в сэндбоксе У, и пусть там каждый работает со своей версией, потом чем-то отдельным сливать изменения (пример: firefox2, firefox3, профили, или даже ~/.kde3, ~/.kde4). Или нужно добровольно-принудительно выдать второй capabilities только на чтение, но оно того не стоит. Суть проблемы-то в чём? Что "конфигурация приложения", "параметры сборки пакета", оказывается, неявно включают какую-то БД, и нет средств в пакетном менеджере эту зависимость явно описать, набор метаданных не расширяем. А если дать в руки такой механизм (но это ССЗБ с разными версиями того не стоит, тут аккуратность нужна)?

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

потому что конечный бинарник софта в линуксе зависит от кучи параметров: версия gcc с тулчейном, флаги configure, флаги системы сборки, static/dynamic, флаги сборки библиотек, "рекомендуемые" зависимости и т.п. Поэтому из одинаковых исходников на разных конфигурациях линуксов получаются разные бинарники.

> Откуда ясно?!!! Например X может и читать и писать в базу, а Y - только читать. В этом случае версия библиотеки для X должна быть <= версии библиотеки для Y. И не всегда надо обновлятся. Но например библиотека может детектить оборваную транзакцию и автоматически её откатывать, в таком случае всё может работать хорошо до первого (или не первого) сбоя питания когда Y запустится раньше чем X.

> С каждым таким вариантом надо внимательно разбиратся. Них такое умеет?

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

> Запускаем. Профиль не читается. Почему? Почему них не обработал эту типичную ситуацию?

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

> Вот сижу и думаю - какой нахрен ад зависимостей?

Обновляешь Xorg 7.3 -> 7.4 и половина оконных приложений отваливается нахрен.
Допустим, библиотека libxcb изменила мажорную версию 1 на 2 — приходится делать: portupgrade -rf libxcb (безоговорочная переустановка библиотеки и всего ПО, которое от неё зависит).

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

> на апт полагаются? Этот не хуже. Вернее, лучше, поскольку написан не на богомерзком с++ или питоне, как юм, а на православной функциональщине.

> виртуалка - не решение. Речь идет не об отладке, а о продакшене.

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

Так вот -- нормальные дистрибутивы, типа шапки и дебиана, рассматривают себя не как свалку пакетов. Хотя все и стараются делать пакеты независимыми друг от друга, реально они кое-где зависят так, как это в зависимостях не прописано (а прописано в policy и подобном) -- и *такие* зависимости комьюнити дистрибутива тестирует -- посему админ на продакшене не будет юзать другой пакетный менеджер, написанный хоть на Трижды Православном Божественно Функциональном Супер Языке.

__________________________________________

Что не отменяет возможного моего интереса к идеям такого пакетного менеджера.

>Есть. Я не могу одной командой создать новый апаратный ящик. Виртуальный почему-то могу а железный почему-то нет. Может них поможет? :-)

а зачем? tar нынче не в моде?

>Это серваки, между прочим.

вот именно. и виртуализация там нужна совсем для других целей.

>Я другие сетевые файловые системы люблю, более подходящие к конкретному случаю. Хотя можно и через nfs.

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