полного взаимопонимания с dpkg и rpm

оно и так есть же.

Есть версия портежа на плюсах, не помню, как называется.

Только при наличии соответствующих ебилдов.

модуль полного взаимопонимания с dpkg и rpm.

Что, даже бинарники можно будет пересобирать?

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

Тут камаз водки нужен, а не бутылка жигуля.

Paludis? Он какой-то норкоманский и тормозит так же как и portage.

Ну если ты так хочешь.

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

Так что забей и не парься

сохранив всю его функциональность

Получится очередной палудис. И да, быстрее он не будет :]

А вот если переписать с sh на xml..

Wait... OH SHI~~~

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

А ты уверен, что алгоритм решателя зависимостей параллелится?

Суть в том, чито портаж ещё делает очень много операций с диском, ровно как и с вычислениями (потомУ что портажу больше работы, чем всяким пакманам). Хотя я не отрицаю, что его можно сделать быстрее, но максимум тебя врядли удивит.

фрактал уже гентушников троллить начал, ужос

не соглашусь. для поиска есть быстрый eix, а апдейт раз в две недели накатить, так это не проблема, я вообще сознательно добавляю --with-bdeps=yes. хотя можно попробывать и переписать, да.

а какая первая проблема?

портаж ещё делает очень много операций с диском

Из всего времени его тупежа на i/o приходится от силы десятая часть. Остальное время он висит и жрёт одно ядро проца.

А что в нём такого принципиально не параллелящегося может быть?

Пусть портируют pacman =]

Pinkbyte, за пиво работаешь? :)

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

Попробую написать об этом в gentoo-dev в ключе возрождении идеи а-ля Gentoo Bug Hunt. Мне идея кажется стоящей.

Но только надо не переписывать portage с нуля, а улучшать - глядя на существующие альтернативы. Так, часть оптимизаций была заимствована из pkgcore. Без этого portage был бы еще большим тормозом.

Конкретных мыслей нет, но я думаю, что это должно быть что-то на C/C++

paludis уже есть - результат спорный. В некоторых местах - лютый вин, кое-где - фэйл.

Поддерживаю. Надо написать задание на каком-нибудь сайте по сбору бабла.

Я переписывать portage на другом языке не готов, а с питоном знаком почти никак. Так что - фэйл :-(

Ну вот есть у пакета зависимость А и зависимость В. А у них - свои зависимости. Что мешает обсчитывать их параллельно?

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

Что мешает обсчитывать их параллельно?

То, что там слишком много условий, включая circular dependency, sub-slot blockers и т.д.

Ты вообще с Portage team связывался? В курсе какие там алгоритмы крутятся, чтобы знать от чего плясать?

он там и так есть

Возьмешься накидать на коленке параллельный алгоритм для такого решателя для gentoo, глядя в код portage?

А у них - свои зависимости

А у тех зависимостей внезапно могут быть общие зависимости. Вообще тут что-то есть на эту тему: http://comjnl.oxfordjournals.org/content/26/4/293.full.pdf

неееее :) нафиг-нафиг

Ну вот =)

Хотя не, раз уж речь о source-based, то я бы портировал пакетные утилиты из Lunar Linux (lin, lrm, lvu и т.д.) - они действительно быстрее, чем портаж.

У меня кстати идея была для одной фичи в еапи следующий. Чтобы портаж хранил время сборки пакета, например гцц. В ебилды пишется число — время сборки, у которой за одну единицу считается время сборки того же гцц. А потом при выводе, например с ключом -v, портаж брал это число, перемножал и показывал примерное время.

Эх, просто оффтоп для этой темы.

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

Lunar Linux

Оно юзфлаги умеет? А слоты?

было бы хорошо,если бы портежи могли rpm архивы устанавливать,а то делать из rpmа ебилд обновы 1С это пиздец.

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

Сам о таким думал

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

Лично мое видение проекта (ясен пень, лично моё, которым я себе представлял, и вы можете на него положить):

• 100% совместимость с portage. Нельзя ломать существующие вещи и делать их по своему. Ломать можно, только если их ломает сам portage. Иначе это может убить проект в зародыше. Вот когда он станет настолько успешным, что сможет диктовать свои правила...
• БД — это хорошо. SQLite или легкая NoSQL (вроде BerkeleyDB, Tokyo/Kyoto Cabinet). Я склоняюсь к NoSQL.
• Любые дополнительные плюшки (та же работа с БД, например) никак не должны мешать работе portage. Т.е., чтобы можно было установить и удалить сишный клиент в любое время, и он не похерил после себя ничего.
• Язык C/C++. Лично я склоняюсь к C++ (стандарт C++11). С умными поинтерами, for-loop, rvalue и прочими плюшками, позволяющими писать более читабельный, быстрый и безопасный код.
• Сразу обмазаться valgrind и статическими анализаторами. PM должен быть молниеносный (как eix, или даже быстрее, если это возможно). Чтобы не получилось тормозное говно вроде portage или aptitude.
• Сделать обертку для обновления основного дерева и оверлеев (аналог eix-sync, eix-update, eix-remote update). Чтобы во время синхронизации заполнять БД и строить графы зависимостей. В будущем можно попытаться отказаться от emerge --sync, но это не приоритетная задача.

100% совместимость с portage

Отлично.

Я склоняюсь к NoSQL.

Почему?

Сразу обмазаться valgrind

Что думаешь по поводу преждевременной оптимизации?

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

Мне кажется, что это на таком этапе вовсе лишнее. Надо оставить работу с ebuild в виде файлов, но, как я написал выше, сделать обертки для обновления дерева или оверлеев.

Правда, не совсем ясно, что делать с ручным редактированием ебилда прямо в /usr/portage или /var/lib/layman. Или написать хелпер, или (для разработчиков) добавить очень легковесный демон, который будет лишь мониторить изменения файлов через inotify (только это ж сотни тысяч дескрипторов... если оно через epoll работает — тогда ладно, а если нет? а память?).

зачастую говорят что это их paludis ничем не лучше portage.

Лучше хотя бы тем, что применяет user patches независимо от того, дописали ли мейнтейнеры ебилда epatch_user в этот ебилд (а ещё в portage есть ебилды, которые написаны на древнем EAPI, в котором нет epatch_user).

было бы хорошо,если бы портежи могли rpm архивы устанавливать,а то делать из rpmа ебилд обновы 1С это пиздец.

Было бы замечательно если б ты для начала хоть немного мануалы осилил Gentoo Development Guide - RPM Sources

ЕМНИП, megabaks показывал, как такое сделать в portage

Я склоняюсь к NoSQL.

Почему?

Я полагаю, что в случае, когда в таблицах будут сотни тысяч или даже миллионы значений (связи, зависимости), то NoSQL тут будет более уместен, чем SQL (мы же говорим об безсерверных БД? а кроме SQLite ничего в голову не приходит из SQL).

Нам нужны очень быстрые выборки по ключам, а не слишком заумные SQL запросы с кучами JOIN (которые могут долго исполняться и ставят под угрозу скорость всего проекта). IMHO.

Что думаешь по поводу преждевременной оптимизации?

эээ... тогда стоит заняться оптимизацией после первого рабочего прототипа. Не фанатично, но и вовсе не забывать о ней.

Лучше хотя бы тем, что применяет user patches независимо от того, дописали ли мейнтейнеры ебилда epatch_user в этот ебилд (а ещё в portage есть ебилды, которые написаны на древнем EAPI, в котором нет epatch_user).

{Наличие/Отсутствие} user patches спорная фича. Наличием нечего гордится потому что значит в аппстриме либо в ebuild-е что-то не так. И отсутствие тоже не минус потому что либо значит „именно так и задумано“ ™ либо майнтрейнер невменяемый упоротый слоупок.

Гентушникам надо взять пример с сусеводов и переписать portage на руби.

У меня кстати идея была для одной фичи в еапи следующий. Чтобы портаж хранил время сборки пакета, например гцц. В ебилды пишется число — время сборки, у которой за одну единицу считается время сборки того же гцц. А потом при выводе, например с ключом -v, портаж брал это число, перемножал и показывал примерное время.

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

Гентушникам надо взять пример с сусеводов и пользоваться сусей.

мы же говорим об безсерверных БД?

Не вижу проблемы при необходимости использовать серверную.

А вообще, ИМХО, тут нужно масштабное тестирование.

За эталон принято брать время сборки bash'a. Не могу найти, где читал об этом.
Время получится очень примерное, потому что зависит от числа потоков сборки и параллебельности компиляции пакета.

Не могу найти, где читал об этом.

http://www.linuxfromscratch.org/lfs/view/development/chapter04/aboutsbus.html