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

>Это у тебя от незнания.

Ну может быть

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

А это не проблема репозитария?

>Про сторонние репо никто даже не заикается.

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

>Попробуй поставь файрфокс2 одному пользователю и файрфокс3 другому. Или рядком поставить 32-х битную и 64-х битную версию.

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

> остальное экзотика имхо и должно умереть
Смерть линуксоидам! Зачем они нужны? Их слишком мало.

посмотрим что за вещь...

И что, когда ждать его в LSB?

>kpackage умеет работать с рпм и деб, не совсем универсально, но остальное экзотика имхо и должно умереть )

rpm5?:)

>я так понял никто не прочитал по линку что написано. я хочу такой манагер себе в бунте.

да, но пукнуть обязательно надо было

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

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

>А это не проблема репозитария?

а дальше что? еще напиши, обратитесь к администратору.

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

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

ну и прощай новый/старый/сторонний софт. или здравствуй ./configure & make & make install

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

Например, одному пользователю нужно одно, а другому - другое.

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

Почитай, о чем там речь. Нет никакого зоопарка либ. И обновляются они точно также, централизованно.

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

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

>А если каждую, что у нас сейчас есть в /usr/bin притаскивать со своей песочницей библиотек, то никаких винтов не хватит.

никто такого не предлагает. Все ровно наоборот.

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

Если они собраны с разными версиями libopenssl - да. Если с одной - нет.

>При таком раскладе подход Gentoo мне больше нравиться, проще мир пересобирать при смене USE флага.

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

> ну и прощай новый/старый/сторонний софт. или здравствуй ./configure & make & make install

Именно здравствуй. Иметь несколько пакетов разных версий -- это извращение или девелоперская машинка, а там ./configure-ом никого не испугаешь.

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

В общем, хочу знать, какова же целевая аудиория этого менеджера пакетов.

>Например, одному пользователю нужно одно, а другому - другое.

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

По сабжу - юзерам не нужен, девелоперы пусть балуются

> Попробуй поставь файрфокс2 одному пользователю и файрфокс3 другому. > Или рядком поставить 32-х битную и 64-х битную версию.

Легко, а какие проблемы-то?

Nao> Помойму авторы nix попробовали найти (золотую?) середину между dependency hell и "dll" hell. Вот только не нарвутся ли и на то и на другое?)

Нет. Они нарвутся и на то, и на другое.

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

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

Какой-то BSD-стайл получается.

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

+1. Это что вообще такое?

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

вот у меня на домашней машине до сих пор слакварь 11, сторонние репо типа slacky.eu и slackware.rol.ru подключены :) все стабильно, все отлично.

по теме: штука хорошая. под слакой работает?

легко? В обычном пакетном менеджере то?

> Чем-то оно мне похоже на GoboLinux

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

авторы придумали себе проблему и успешно ее решили. Какой еще ад зависимостей?

> Какой-то BSD-стайл получается.

Именно. Если мне не изменяет прамять, в DesktopBSD (или в PC-BSD?) такой пакетный менеджер существует уже давным-давно. Но почему-то он до сих пор не покорил мир.

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

а что, лучше как в оффтопике, искать непонятно где новый redistrubutable package 2008 best+ SP1?

тоесть с posix и lsb он не совместим?

в LSB сказано rpm или наличие приблуды, которая из рпм сделает человеческий пакет

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

http://sites.google.com/site/agutilities/Home/my-own-foss-staff/WayRound-GNUL...

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

> Какой-то BSD-стайл получается.

нет. BSD стайл это если сразу поставить WinXP и не сношать моск. Вот это Ъ БСДстайл.

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

Зачот! больше велосипедов, хороших и разных

Ну ручками я понимаю. Вопрос ведь чтобы это пакетный менеджер делал. Вот я недавно сталкивался с задачей. Решил новый диджикам из сизифа поставить. Ну так старый затёрся... А новый не заработал. Неприятно. Было бы отлично если бы была в пакетном менеджере возможность ставить рядышком два пакета разных версий.

Чаще такое конечно нужно разработчикам. Но и как простой пользователь я раз или два сталкивался с такой проблемой. Хотел вот например поглядеть, как новая версия екиги, лучше ли стала работать или нет. Ясно дело для этого пришлось обновить екигу. Старая версия удалилась. Новая глючила. Пришлось извращаться чтобы вернуть старую. А так поставил бы рядышком, глянул что к чему и снёс бы. Всего делов.

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

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

вполне себе можно сделать и без велосипедов. На работе постоянно такие вещи делаются с жабой. А думать за юзера и файлопомойка в /nix не нужны

>Проект Nix родился в Университете Утрехта в Нидерландах, название происходит от голландского «ничто».

какбы намекает

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

>Пришлось извращаться чтобы вернуть старую.

А в дебиане с этим проблем нет, просто ставишь прошлую версию и все.

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

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

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

>В общем, хочу знать, какова же целевая аудиория этого менеджера пакетов.

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

>Один фиг тянуть получится практически не больше данных, чем при статической сборке.

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

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

не получится. в никсе такие же зависимости.

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

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

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

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

>А в дебиане с этим проблем нет, просто ставишь прошлую версию и все.

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

Я уверен что в дебиане есть какое то решение для этого. Озвучьте же его господа.

З.Ы. В генту открыл для себя недавно demerge. Хорошая штука для "откатов".

> легко? В обычном пакетном менеджере то?

Когда я работал под Gentoo, у меня было несколько версий Python и GCC. И конфигуратор, чтобы указать какая версия будет работать при запуске python или gcc без указания версии в имени команды.

qt и gtk тоже было несколько версий.

>авторы придумали себе проблему и успешно ее решили. Какой еще ад зависимостей?

от либы ZZZ зависят пакеты X и Y

пакет X в новой версии 1.2 требует новую версию либы ZZZ

пакет Y не собирается с этой новой версией 1.2 либы ZZZ

Выход:

1) не обновлять X. ждать пока Y начнет собираться с новой версией ZZZ 1.2

2) обновить X, выкинуть Y

3) переделать ZZZ12-1.2, которая ставится параллельно со старой и собрать каждую программу со своей версией либы ZZZ.

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

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

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

>Легко, а какие проблемы-то?

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

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

>помогающий выбраться из "ада зависимостей"

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

>Когда я работал под Gentoo, у меня было несколько версий Python и GCC. >И конфигуратор, чтобы указать какая версия будет работать при запуске >python или gcc без указания версии в имени команды.

>qt и gtk тоже было несколько версий.

Да, слоты в Генту это хорошая вещчь. Но видимо некоторым хочется более мелкое "дробление" на "слоты".

Хороший пример - недавно решил поставить "на посмотреть" последние иксы со всей шелухой. Посмотрел - не понравилось, решил вернуться назад... тут мне помог разьве что demerge, которым я предварительно запомнил "состояние" системы. Как бы было хорошо если бы эти новые иксы поставились в отдельный "слот" и мне бы пришлось бы только удалить новую версию.

> При таком раскладе подход Gentoo мне больше нравиться, проще мир пересобирать при смене USE флага.

а мне portage как раз не нравится лишними пересборками, без которых можно было бы обойтись. Например, от старой версии пакета A зависел пакет Б, в новой версии стало от А1 зависимости Б1 и В1. В итоге, не можем установить одновременно Б1 и А, конфликт Б и Б1 на ровном месте. Нужно догадаться снести Б (или другие зависимости от А), снести А, поставить в правильном порядке Б1 и В1, накатить А заново -- лишняя пересборка на ровном месте от того, что поменялся ебилд А в А1. Пример, xorg, mesa, nvidia-drivers 7.3 и выше. А здесь в nix число таких "ломающихся" зависимостей должно быть минимизировано, плюс, можно не обновлять А до А1 (и вытягивать В1), если нужен только Б1 новый, а А подойдёт и старый.

smart --gui

> Это не собачье дело пакетной системы думать за пользователя что ОН хочет. Хочет пользователь иметь в рядок firefox 1.5, 2 и 3 — значит хорошо бы чтобы имел. Хочет и 32-битный и 64-битный mplayer'ы — значит так надо.

+1. Пакетная система неявно завязана на версии glibc и тулчейна binutils, gcc, и т.п. Но при этом либо нужна интеграция с системой сборки чтобы пересобрать потом с новым тулчейном, либо такая интеграция наоборот, слишком сильная, с явными зависимостями. А тут речь о том, чтобы сделать более слабосвязанную систему, с более гибким набором зависимостей, отвязать систему сборки от пакетного менеджера.

> nix вообще поддерживает сборку из сырцов ака генту. так что никто не мешает оптимизировать кол-во библиотек.

да, как-то недоделано немного: сборка из тарболлов есть, из SVN/git нету. Сборка из SRPM есть, а из ебилдов/PKGBUILD'ов нету (хотя там нужно просто готовый рецепт сборки на одном языке перевести/оттранслировать в другой, тот что в nix).