Дениска Попов, ты ли это?

язык вторичен. а возможно и 3-ричен.
3-ричен

Что ты имел в виду?)

И да, пакетный менеджер это основа дистрибутива, по сути сам дистрибутив отчасти. Пускай и с трудом, но в gentoo его можно сменить - уже что-то. Можно ли сказать это о, например, apt в debian или rpm в красношапках?

В любом линуксе можно с определенным успехом накатить pkgsrc, так что...

Можно ли сказать это о, например, apt в debian или rpm в красношапках?

Можно в любом. Пакетный менеджер это приложение, ничего сверхестественного в нем нет.

Другое дело, что гентушники любят компилировать, а не писать код.

Можно в любом. Пакетный менеджер это приложение, ничего сверхестественного в нем нет

попробуй сменить в дебиане apt на pacman, о результатах доложишь

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

В кач-ве фана

проще заново, в качестве фана

перепиши на malbolge

Это скучно, давай на Befunge.

В Alt для установки rpm-пакетов используется apt. То есть они, будучи отпрыском Madrake, смогли.

в списке важности идет под №3

суть не чуть, но доля правды в этом есть чуть менее чем полностью. поэтому каждый кто начинает делать что-то в направлении сабжа (Переписать Portageю..) поздно или рано приходит к идеи что данные в ебилдах «для себя» нужно держать в более удобоваримой форме^формате

на хаскелле

легкоподдерживаемость значительно выше

Хорошая шутка

Что не так?

Всё не так. У хаскеля порог вхождения выше.

Ты вынуждаешь отписаться от тэга. Не нужно так, пожалуйста.

Хочешь переписывать - переписывай. Не хочешь соблюдать "пиши код, блять!", то пость в толксы, будь добр.

бери выше, сам Поттеринг к нам пожаловал (с красношапки походу тырнули вот и ищет прибежище)! :)

Paludis так и не взлетел.

в каком смысле paludis не взлетел ?

Что скажете? Или работает медленно не по причине питона?

На прологе пиши.

Основная проблема портажей не IO, а однопоточность.

Ну хоть один реальный совет на весь тред, а то тут набижало экспертов с советами уменьшить IO и сделать бинарные файлы :)

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

Осилили. Задачу дали студенту на Google summer of code, он сделал до состояния, когда оно может распарсить половину ебилдов, потом каникулы закончились и он на проект забил. В своем блоге он писал, что нужно банально дорабатывать разбор грамматики bash.

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

Лучше начни с допиливания libbash - даже если портаж не сделаешь, оно пригодится.

См. pkgcore как контрпример.

А насколько он рабочий?

Мы говорили про поддерживаемость/maintanability, а не про порог вхождения. Это очень разные вещи.

в каком смысле paludis не взлетел ?

В прямом. Его использование так и осталось уделом очень малой доли Gentoo-пользователей.

На ниме должно выйти быстрее, да и типы там нормальные есть и прочее.

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

Paludis так и не взлетел.

«А всё почему? И по какой причине? И какой из этого следует вывод?»

[Режим капитана]Сам portage переписывать можно 100500 раз на всём чём только заблагорассудится от тёплого-лампового basic-а до brainfuck-а и от того на каком именно ЯП реализован portage ровным счетом ничего глобально не изменится. А всё потому-что «тормоза» они вовсе не в том ПО что именуют portage. Тормоза заложены изначально в самой идее portage some shell-->portage(python)-->ebuild(синтаксис почти shell)-->eclass(синтаксис почти shell)-->coreutil/busybox/autoconf/automake/и т.д. О чём речь отличная идея из python-а тыкать недоЯП eclass/ebuild эмитирующий shell а затем совершать собственно работу ради которой оно и задумано…[/Режим капитана]

Ну хоть один реальный совет на весь тред, а то тут набижало экспертов с советами уменьшить IO и сделать бинарные файлы :)

ВНЕЗАПНО

хаскелле

легкоподдерживаемость

ага, только кто будет поддерживать? пусть даже и легко.

В лучшем случае ты добьёшься маленького линейного прироста.

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

Я в курсе про GIL.

Ну это Ок. А всё остальное тебя не смутило?

Кстати да, homebrew, который на ruby написан, вполне шустро зависимости считает и с use флагами там проблем нет. Да и macports тоже не испытывают этих проблем.

Там тоже 100500 пакетов с зависимости друг на друга и всякими шутками как сабслоты?

Там тоже 100500 пакетов с зависимости друг на друга и всякими шутками как сабслоты?

Да, но не 100500, а 3200 на сегодняшний день.

Ну как-то это ниочем, в портаже одних хацкельных пакетов ~1500 не говоря о софте.

Портеж разве не в IO упирается? Всмысле он же там миллиарды файлов высирает, по которым надо искать.

А на pypy портаж не пытались запускать?

начни с допиливания libbash

там же какая-то адская смесь ANTLR и boost::spirit? допиливанию не подлежит

Тогда проблему можно решить: выкинуть половину пакетов и флагов из portage! Ускорится раза в 4.

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

Кажется, init_6 такое проворачивал, создав свой stage с урезанным деревом и кучей выброшенных из него пакетов.

Ага сперва это был опыт ради замера разницы скорости portage. И да чистая разница от влияния обработки ненужных пакетов по сравнению с минимальным деревом портежейй в котором только содержимое stage3 в 3,875 раза т.е. да примерно в 4-ре раза. А потом я начал пилить дистрик но это уже совсем другая история…

А на pypy портаж не пытались запускать?

Овчинка выделки не стоит.

Портеж разве не в IO упирается?

Да и в IO тоже. Но «Зри в корень» проблема портежей не в конкретно IO и не в «миллиардах файлов». Это всё следствия а проблема в самой идее.

Итак ещё раз с самого.

[Уголок маньяка]

У нас есть ebuild - синтаксис фактически любого shell скрипт. Его задача - несет в себе значения переменных и вызывает eclass-ы.

eclass - библиотека типовых действий для некоего конкретного случая. Синтаксис тот же shell скрипт что и ebuild. Фактически шаблон для некой однородной группы ebuild-ов - gnome/KDE/xorg и т.п.

Для задействования конкретного eclass-а мы его я явном виде прописываем в ebuild-е.

Совокупность ebuild-ов и eclass-ов - дерево портежей или portage tree.

Далее у нас есть парсер всего этого счастья - portage. ЯП - python. portage фактически собирает алгоритм сборки любого приложения по переменным из ebuild-а подставленным в функции из eclass-а. На выходе получается длинная простыня в которой учтены индивидуальные особенности каждого приложения и если надо в нужный момент накладываются некие заплатки. Практически эта простыня (почти что) на shell - т.е. может (с оговорками) быть выполнена на любой командной оболочке. А фактически роль командной оболочки берет на себя тоже portage.

Выводы:

• сотни промежуточных файлов плодят ebuild-ы и eclass-ы ибо (недоЯП) они иначе попросту не могут обмениваться данными между собой.
• IO закономерно большой поскольку файлов чуть менее чем дохрена
• ко всему этому не добавляет счастья и ЯП на котором выполнен сам «парсер»/portage поскольку python и GIL

Т.е. чтоб было на порядок быстрее нужно выбрать ЯП без GIL для парсера, позволить eclass-ам быть таки полноценными библиотеками на том же ЯП что и сам парсер, ebuild-ы превращаются… превращаются ebuild-ы… ага в полноценные программы на том же ЯП что и eclass-ы и сам парсер - таким образом обмен данными организовать будет на порядок проще и необходимость в сотнях промежуточных файлов просто сама собой отпадает.

И вообще просто прекрасно если у парсера/библиотек-eclass-ов/ebuild-ов будут свои собственные (биндинги к) coreutils/busybox с картами и продажными женщинами. Т.е. в текущей реализации portage нет ничего хорошего в том, что в ebuild-ах разрешено напрямую использовать любой shell код - это ведет к излишнему и ненужному усложнению и только лишний раз замедляет и усложняет контроль за ними. Взамен этому должен быть минимальный набор внутренних функций сразу со всеми нужными проверками и т.д. а на любой прямой вызов shell кода должен идти мат о том что так делать ооооочень нехорошо.

[/Уголок маньяка]

Я выдохнул.

Интересно сравнить время сборки одного и того же пакета в генту и в фрибсд. У них относительно недавно изменился пм. А ебилдьі у них теперь на ямле емнип..

// ZuBB

Угу и вместо gcc у них вроде clang&llvm

Там в принципе все пакеты через слоты сделаны, вообще все. Там концепция как в nix'е. Пакетов там поменьше, чем в портаже, но там их просто не разбивают на мелкие части.

А что у нас скриптовое остается без gil?

Ну это опять же очень сильно упрощает рассчет зависимостей. В Генте глобальная помойка с кучей пакетов с юзами и слотами, давайте сравнивать с аналогичными вещами, всякие rpm/nix/guile это не аналогичные вещи.

Они решают ту же проблему, но быстрее проще и универсальнее