Nix окончательно решит проблему зависимостей

>>8. > and allows a choice of SQL back ends on installation.

>Это прикол что ли, они конфиги в sql-базе хранят?

не, это вроде хранения базы пакетов из портежа в mysql (FEATURES="metadata-transfer", например, чтобы rdep.py работал моментально)

> Почему не git

> просто положите их в git и реплицируйте на здоровье.

> в 0install, или тут, или в git

Кажется, у кого-то появился новый волшебный молоток %)

вполне себе старый ))

> Интересно, а default.nix можно автоматически из готовых ебилдов строить?

/me негодуе. Сборка из тарболлов/DEB/RPM вроде есть, а ебилдов всё ждём...

https://svn.nixos.org/repos/nix/nixpkgs/trunk/pkgs/build-support/release/

если ещё полазить по репозиторию, обнаруживается ссылко на http://nixos.org/nixos/ "NixOS is a Linux distribution based on Nix, a purely functional package management system."

Интересное заявление насчёт "purely functional". Или это просто Хаскелль окончательно съел мозг?

мда, вот он, Ъ чисто конкретно функциональный пакетный менеджер
http://nixos.org/docs/papers.html
А вы всё DEB vs RPM.

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

В rpm это одна команда. В дебиане - три.

>dpkg-buildpackage -rfakeroot

Как минимум указание fakeroot и отсутствие стандартной структуры для постройки как у rpm. Плюс рыться в двух файлах на предмет указания новой версии вместо проставления ее в сборочном спеке.

>все он видит, их надо зафиксировать,чтобы они заново не устанавливались.

Т.е. еще телодвижения?

>> dpkg-buildpackage -rfakeroot

> Как минимум указание fakeroot и отсутствие стандартной структуры для постройки как у rpm.

Ну вообще-то в RPM для этого нжен mock или там abe, так что еще неизвестно, чт о проще.

>Охуевший перец здесь ты. Действительно, мама с папой зря тебя придумали. anonymous (*) (25.12.2008 11:33:39)

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

Идея интересная, но не более. Всё равно с течением времени рост процессорных мощностей убъёт все бинарные дистибутивы. Ну будет OpenOffice собираться две минуты, ну и чё?

> Я твой рот ебал, черт ебаный.

> Прежде чем вякать - залогинься, тогда и поговорим.

Опаньки, чоткий пацан в треде. Всем бояццо. ;)

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

Что же это - не велосипед? В chroot ещё небось нужно debootstap пускать, развернёт он там пол-системы - так ведь? Надо ждать тогда btrfs, с copy-on-write. Вот под виндами всё плохо-плохо - а такие вещи проблем не представляют. В nix же обещают чудеса и красоты, неясно правда - насколько оно всё функционально в реальности.

А ещё, иногда бывает нужна какая-нибудь не стандартная версия glibc, для сборки бинарников например. Тут наверное без велосипедов точно не обойтись сейчас, даже chroot не поможет.

> chroot ещё небось нужно debootstap пускать, развернёт он там пол-системы - так ведь? Надо ждать тогда btrfs, с copy-on-write.

man ln

> А ещё, иногда бывает нужна какая-нибудь не стандартная версия glibc, для сборки бинарников например. Тут наверное без велосипедов точно не обойтись сейчас, даже chroot не поможет.

Поможет

Всё, что ты написал здесь, напиши разработчикам YaST'а. Серьезно. Может быть, они внимут твоим словам.

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

Речь не идет о хранении данных - только о представлении - очевидно, что все сведения о графе и так уже есть в списке пакетов и наборе их зависимостей - нужно только их распарсить и нарисовать. Кроме того, совершенно необязательно рисовать сразу весь граф по ползать по нему мышью, зумить колесом - ясно, что среди тысячи пакетов на одном планшете разобраться будет невозможно. Но можно например найти пакет по имени, кликнуть по нему мышью и выбрать в меню "показать зависимости в виде графа" - будут нарисованы только те вершины, которые находятся "не очень далеко" от выбранного пакета (то, насколько "не очень далеко", можно задать где-нибудь здесь же двумя числами - число зависимых уровней "вверх"/"вниз")

> Далее, для подобных красивостей, чтобы человек мог хотя бы увидеть общие формы отношений объектов представленных графом нужно реализовать алгоритмы размещения, трассировки рёбер. Вы хотя бы на 50 вершин графы видели автоматом размещённые? попробуйте dot - полюбуйтесь. Далее есть жёсткие зависимости а есть мягкие - вес рёбер?...

Ситуацию облегчает тот факт, что граф пакетов - не просто произвольный граф, а направленный граф в идеале без циклов (здесь правда не уверен - подозреваю, что могут быть и циклические зависимости тоже, но мне кажется их стоит избегать). Для автоматического размещения таких графов существуют разные алгоритмы - самое простое, что приходит в голову - рисовать граф слева направа сгруппировав вершины по рангам (например: qt:ранг0, kdelibs:ранг1, kate:ранг2, konsole:ранг2). Про то, что в одном окне не обязательно рисовать абсолютно все вершины уже написал выше.