Желающие принять участие в написании альтернативы portage на C++ просьба отписаться

очередного paludis

Дописать существующий не судьба?

А ты уже определился что именно писать нужно?

Пустой треп лучше перенести в вышеуказанный тред в толксах.

Какое совпадение.

Два месяца назад я пытался переписать Portage на Perl.

Я могу присоединиться через пару дней или неделю-две.

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

Предположительный workflow:

• Собираем ядро участников
• Создаем форум/рассылку с обсуждением нюансов, выбором тех или иных вещей
• Пишем парсер ебилдов
• Реверсим portage и описываем алгоритмы (я считаю описание алгоритмов весьма важным моментом для всех)
• По мере расшифровки алгоритма описать, что нам надо хранить в БД и как оптимальнее
• Создаем прототип

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

Готов помочь в тестировании.

Чем эта альтернатива будет лучше portage?

чем закончилась история?

почему такое запредельное желание сделать это на с/с++?

1) core софт системы 2) предполагается что упираемся не в IO, а в CPU 3) надо же на чем то писать, учитывая специфику линуксоидов, все развалится на этапе выбора ЯП, потому лучше выбрать средний адекватно/компромиссный вариант для этой задачи, озвучить как аксиому, кто не согласен - нафиг

В план между 2 и 3 пунктом нужно вставить «Разбираемся, почему тормозит существующий portage и paludis». А то ведь тормозит то он, не потому что плохо закодирован, а потому, что такой принцип работы. И БД может не помочь.

Ниасилил и выбросил.

предлагаю не переть как танк привязыватся сразу к С/С++ а обговорить все высоко уровневые детали.

а поучаствовать в подобном проекте в принципе желаешь?

Гентушники, есть чё по мелочи? (комментарий)

Гентушники, есть чё по мелочи? (комментарий)

Основная мотивация:

Сделать package manager быстрым, в том числе и поиск, и расчет зависимостей (сравни поиск emerge и eix).

Делать предрасчет зависимостей только при очередной синхронизации дерева/оверлеев и хранить результаты в быстрой БД, и не шерстить по всему дереву, не заглядывать в ебилды на каждый чих, уменьшить I/O и потребление памяти.

// also cast wota

Вброшу, пожалуй и тут.

Я вот предлагаю участникам дискуссии подумать над использованием для такого проекта графовой БД. Возможно, она может сильно ускорить расчет зависимостей.

ЗЫ. Участие в проекте не обещаю, т.к. в ближайший год вряд ли смогу выделить время. Разве что в качестве тестера.

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

не совсем так. Portage тормозит из-за слегка кривого алгоритма расчета зависимостей. Особенно в последних версиях с EAPI=5, после добавления сабслотов и прочих ништяков. И я не совсем уверен, что собравшаяся толпа сможет написать лучше.

Ну, потенциально я. Правда «наскоками»: неделя-две активной работы с перерывами. Думаю, все так, так что нужно организовать систему task'ов.

Предпочитаю C++, хотя если решим что на С - соглашусь. С другой стороны готов помогать тем, кто видит в C++ какие-то gap'ы по сравнению с C.

Уже думал над таким. Вот размышления:

Пишем парсер ебилдов

Парсером ебилдов является bash. Загляни во внутрь.

Реверсим portage и описываем алгоритмы (я считаю описание алгоритмов весьма важным моментом для всех)

Вот это самое главное.

Проблему portage вижу в следующем:
1. Python
2. Чтение огромного количества маленьких файлов
3. Скармливание каждого ebuild'а bash'у, чтобы узнать зависимости.

Поэтому ИМХО нужно понять логику работы portage, а потом изменить все, начиная с формата ebuild. То есть переписать с нуля. При этом нужно сделать конвертор ebuild'ов в новый формат.

Писать не с нуля не согласен.

графовой БД

подробнее?

Нужно делать распараллеливание работы на все процессоры. В существующий портаж. Кстати, что случилось с этой штукой, ее приделали к портаж? http://www.gentoo.org/proj/en/libbash/

Ну это я и имел в виду. Простое переписывание на плюсах и с БД не сильно поможет. Сначала нужно разобраться, что тормозит.

а поучаствовать в подобном проекте в принципе желаешь?

Нет. Пакетный менеджер, написанный на скриптовом ЯП, будет жутко тормозить же.

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

Например

Или http://ru.wikipedia.org/wiki/%D0%93%D1%80%D0%B0%D1%84%D0%BE%D0%B2%D0%B0%D1%8F_%D0%B1%D0%B0%D0%B7%D0%B0_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85

http://www.opennet.ru/opennews/art.shtml?num=30256

ты тот же анон?

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

ты тот же анон?

Нет.

Да, я еще строго за unix-way:
- максимальная модульность (пусть на уровне структуры исходников).
- использование BD допускается, но должна быть возможность и такстовых данных. Соединяя с с предыдущим пунктом - должен быть модуль «text» и модуль «bd», и их переключать (пусть на уровне ./configure / USE флага).
- сначала написать чтобы работало, в виде комментов оставлять // здесь можно оптимизировать (ну, или TODO вести).
- все, что можно изменять - в файл конфигурации. Чтобы ничего не было прибито гвоздями.
- обязательно CLI. Gui если нужно, потом допишем; опять же привет модульная структура.
- генерация обильных логов (максимальные возможности по дебагингу)
- документирование и еще раз документирование. Много комментов в коде. Описание цели каждого файла, каждой функции и т. п. Может отдельно какие-то описания/диаграммы/... Максимлаьно облегчить работу тех, кто будет контрибьютить в будущем.

Еще раз повторюсь: самое главное на данный момент - описать алгоритм работы существующего portage.

нет, тут два или три анона в треде.

Подписываюсь.

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

Нет, неправильно.

Я лишь считаю, что на скриптовых ЯП лучше не стоит писать системные приложения.

а NIFы будут к модулям на эрланге?

как думаешь сколько здесь найдется людей готовых писать более-менее нормальный код на сях/плюсах?

описать алгоритм работы существующего portage.

да нет там особого алгоритма. Просто строится граф зависимостей и они собираются вместе с пакетом.

а каково твое мнение о mercurial (не в сравнении с гитом)? правильный ли инструмент выбран для затачи такого класса?

Если ты в курсе внутренностей — может, посодействуешь?)

Если ты в курсе внутренностей — может, посодействуешь?)

вечером в жабир стукну.

Система Mercurial написана на Python, хотя чувствительные к производительности части (например, своя реализация diff) выполнены в качестве модулей-расширений на C

Ничего плохого.

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

Уже ответил выше.

извини, все что приходит на ум это

умом Россию не понять

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

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

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

пс: выше по треду товарисч тоже дело говорит (как минимум идея заслуживает внимания)

Желающие принять участие в написании альтернативы portage на C++ просьба отписаться (комментарий)

получается вам обом не по пути..

С этим проблем как раз таки нет — Perl доступен в базовой поставке любого UNIX'а.

perl - гадость. Тут даже не дело вкуса, а просто обилие глюков, необходимость его патчить (как в OpenBSD, например), etc.

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

касательно БД - то же самое. В основной функционал её вносить - не самая разумная идея, но после установки полноценной системы её можно использовать для ускорения операций, например как eix это делает.

просьба здесь отписаться и подписаться

подписался и отписался

Просто строится граф зависимостей и они собираются вместе с пакетом.

Не просто. Загляни в ebuild. Там модули подключаются: для работы с разными типами make, для работы с «составными пакетами» как kde, qt и т. п. Есть разного типа зависимости и т. п. Плюс есть несколько типов API (сейчас последняя 5-я, как я понял).

для работы с разными типами make, для работы с «составными пакетами» как kde, qt и т. п. Есть разного типа зависимости и т. п.

это фигня и к алгоритмам не имеет отношения. Просто модули с командами, ничего особенного.

Как вообще база выглядеть будет?

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

Писать не с нуля не согласен.

Был тут geekless, который с нуля DE писать собрался. А воз и нынче там, как говорится.