LINUX.ORG.RU

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

 , ,


9

17

В продолжение обсуждения: Гентушники, есть чё по мелочи?

Пока в толксах разглагольствуют о нужности или ненужности C/C++ и очередного paludis, я решил создать этот тред. Пусть он будет только трекером участников.

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

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

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

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

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

Ответ на: комментарий от FRCTLL

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

И как уже выше говорилось, стоит всё делать изначально на уровнях интерфейсов. Вот я желаю использовать NoSQL, а товарищи слева — SQLite или графовые БД. Каждый сможет хранить инфу в удобном формате и реализовать детали выборки в своем плагине (библиотеке).

Лично я себе пока представляю таблицы с сущностями (ебилд конкретной версии, слот, субслот, и т.д.), и таблица ребер графа зависимостей (с индексами). Пока всё сумбурно. Надо доки подготовить.

Chaser_Andrey ★★★★★
() автор топика
Ответ на: комментарий от Kroz

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

Разве палудис не писал свой собственный парсер?

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

Поддерживаю.

Chaser_Andrey ★★★★★
() автор топика
Ответ на: комментарий от x0r

так может для начала закончить libbash?

Найти узкие места в существующем portage? Зачем и кому это надо? Лучше же еще понасоздавать 100500 тем про то что „portage тормозит“. Но ныне в тренде уже „Давайте запилим клон portage на {С/C++/жабе/подставь сюда свой любимый ЯП но не python}“

init_6 ★★★★★
()
Ответ на: комментарий от init_6

вся суть опенсурса и его коммюнити.

x0r ★★★★★
()
Ответ на: комментарий от x0r

так может для начала закончить libbash?

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

iVS ★★★★★
()
Ответ на: комментарий от Chaser_Andrey

У portage есть фатальный недостаток :}

Если намеренно искать но недостатки можно найти у всего.

Почему все мило умалчивают о том что им дает eapi 4, 5 и при этом на каждом шагу трезвонят о том что „portage тормозит“?

(и да я дам еще раз ту ссылку) Вот вы все те у кого „portage тормозит“ у вас вот этот portage тоже тормозит? И если да то в каком конкретно месте и с конкретными консольными выхлопами а не так как всегда в сторону лужи.

init_6 ★★★★★
()
Ответ на: комментарий от RedEyedMan3

А кто будет обеспечивать совместимость со всякими новыми EAPI ?

Ну и в идеале, если сделать все относительно не плохо, будет еще один paludis который будет точно так же тормозить как и portage который изначально форкали для того чтобы ускорить… oh shit!

init_6 ★★★★★
()
Ответ на: комментарий от feofan

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

Зачем? Топологическая сортировка даже в (g)make есть. Больше операций с графом зависимостей не будет. Так что видимо графовая субд не нужна.

nerdogeek
()

И да, ненужно! Тормозить будет так-же и вечно в отстающих по фича. Сомневающимся смотреть paludis.

zunkree
()
Ответ на: комментарий от Chaser_Andrey

Безуспешные попытки

Все уже поняли, что срача не избежать.

anonymous
()
Ответ на: комментарий от anonymous

На D можно, чисто ради с языком поковыряться, но опять-же сомневаюсь что станет сильно быстрее.

zunkree
()
Ответ на: комментарий от Chaser_Andrey

Возможно, но намного результативнее если так C++ любиться, рефакторить то, что есть и тормозящий python код переписывать на Boost.Python или аналоги. И да — развивать libbash на «православном» C++ тоже никто не мешает. Поттеринги плин.

zunkree
()

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

Mr_Gentoo
()

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

Не следовать законом физики. Я сомневаюсь, что ты умнее zmedico, который девит portage в одиночку.

Zlogene
()
Ответ на: комментарий от anonymous

Суть в том что:

  1. Будет вечно отстающим по фичам от портажа.
  2. Без libbash будет просадка по производительности.
  3. Не факт что будет значительно (минимум на 50%) быстрее.

Поэтому, если у кого свирбит NIH идите на gentoo-dev и просто спросите у разрабов чем можете помочь, пользы больше будет.

P.S. На D бы возможно взялся, чисто ради изучения языка и for fun, но сейчас набигут с нинужно и будут в чем-то правы.

zunkree
()
Ответ на: комментарий от zunkree

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

ZuBB ★★★★★
()
Ответ на: комментарий от ZuBB

Пускай переведут, пускай сделают, пускай допилят, пускай улучшат, а Я буду рассказывать как надо. Мне нравится такая позиция, да.

zunkree
()
Ответ на: комментарий от zunkree

Пускай переведут, пускай сделают, пускай допилят, пускай улучшат

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

а Я буду рассказывать как надо. Мне нравится такая позиция, да.

да ты еще большый балабол нежели они.

ZuBB ★★★★★
()
Ответ на: комментарий от zunkree

Пускай переведут, пускай сделают, пускай допилят, пускай улучшат, а Я буду рассказывать как надо. Мне нравится такая позиция, да.

Ну так ради этого же все и задумано. ;)

init_6 ★★★★★
()
Ответ на: комментарий от zunkree

На D бы возможно взялся

В этом вся суть. Если выберут D — возьмётся 1-2 человека, если C/C++ — вполне возможно набрать 10 и больше разработчиков.

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

anonymous
()
Ответ на: комментарий от Zlogene

его по праву считают *main portage coder*

знаю что он главный

(Этак от него зависит %95)

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

ZuBB ★★★★★
()
Ответ на: комментарий от Chaser_Andrey

Надо изучить механизмы построения зависимостей

Который сейчас в portage? Чтобы сделать такой же тормозной?

FRCTLL
()
Ответ на: комментарий от anonymous

вполне возможно набрать 10 и больше разработчиков.

мсье оптимист. осталось две вещи: (1) услышать ответ на мой вопрос и (2) спросить у оставшихся еще один мой вопрос. ТС уже дал ответ.

ZuBB ★★★★★
()
Ответ на: комментарий от nerdogeek

Зачем? Топологическая сортировка даже в (g)make есть.

Затем, что на сегодняшний день эта самая топологическая сортировка проводится в нутри портежа на каждый чих по нескольку раз. Я же предлагаю делать эту операцию однократно после eix-sync при обновлении базы. А затем заменить простыми выборками из БД. ИМХО такая схема будет работать гораздо быстрее.

feofan ★★★★★
()

Готов что-нибудь писать раз в неделю\две.

jcd ★★★★★
()

Почему C++, а не чистый C?

anonymous
()
  • Не понимаю, чем не устраивает paludis. Он как раз на C++.
  • Даже если чем-то не устаревает, по почему бы просто не подправить те места, которые не устраивают? Всё таки сам подход, архитектура программы правильная. Или на этот счёт есть другие мнения?
  • На мой взгляд главное, чего не хватает так это дружественного графического интерфейса. И безопасного автоматического обновления (внешний вид на подобие windows update - простенько и красиво так и так).
Micky53
()
Ответ на: комментарий от Micky53

сынок, ану не лезь, когда старшые дяди разговаривают

ZuBB ★★★★★
()

ниасилит ЛОР этот квест.

а вообще, я бы даже тыкать не стал, вдруг взорвётся? особенно, если учитывать, что ЛОРчане будут делать очередной палудис так же, как и помогают на лоре.

funeralismatic ★★★
()
Ответ на: комментарий от Micky53

На мой взгляд главное, чего не хватает так это дружественного графического интерфейса. И безопасного автоматического обновления (внешний вид на подобие windows update - простенько и красиво так и так).

На мой взгляд тебе на убунту надо.

ritsufag ★★★★★
()

Готов поучаствовать.

trex6 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.