gentoo. графы зависимостей ebuild-ов.

я слабо представляю, как ты хочешь туда ещё и юзфлаги воткнуть. И более чем уверен, что «наглядно» это выглядеть не будет (посмотри хотябы на то во что генерятся зависимости в init системах). А по теме - да самому.

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

Ну как чтоб к примеру если у пакета стоит USE=«gtk+» то четко было бы видно что именно он собой тянет x11-libs/gtk+

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

Подписать над ребром графа USE флаг, который «притягивает» зависимость.

ты видел, что из этого получается?

Представить могу, это очевидное решение.

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

тебе придётся тогда на ребрах это писать, а чтобы очевидно было ещё и подсвечевать как-нибудь, т.к. ребра будут очень большие и названия их будут раскиданы очень не удобно.

Как это оформить это уже другой вопрос. Для начала нужно вытащить сам граф зависимостей.

В общем я такой тулсы не видел, можешь попытаться поискать..

Я тоже пока не находил… Но такая штука была бы очень не плоха.

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

+----------------+
|  pkg-version   |
|   |    |   |   |
| use1 use2 use3 |
+---|------------+
  +-+-+
  | | |

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

ok.

у нас в hackport через какое-то время будет весь функционал для этого, но пока времени на развитие нет, а я занят другими делами :/

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

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

у нас в hackport через какое-то время будет весь функционал для этого, но пока времени на развитие нет, а я занят другими делами :/

ОК. Я пока буду искать и велосипедить.

Иногда же бывают приколы… К примеру вот недавний media-video/ffmpeg -> media-video/libav. Ну и подобные ему случаи когда идет замена ebuild-а. И были же случаи когда пакет просто не развивался долгое время его выпиливали. Или опять же все тот же sys-fs/udev и sys-apps/openrc vs sys-apps/systemd.

Вот для таких случаев подобная штука была бы очень полезна.

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

В идеале неплохо было бы весь граф еще и со связями по USE флагам.

Если всё дерево до конца, то тут только два выхода:

1) Выходить из плоскости в многомерное пространство

2) Делать карту интерактивной

иначе банально не хватит места на это всё, а если даже хватит - будет сверхнеудобно пользоваться

Можно так, например: по умолчанию перед глазами имя атома и его жёсткие зависимости, а вокруг - юзы. При клике по юзу выводятся зависимости, вытягиваемые юзом. И так далее.

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

Я как-то размышлял о трёхмерном фронтенде к portage, но это абалдеть сколько работы требуется. Своими силами точно не управиться.

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

В идеале неплохо было бы весь граф еще и со связями по USE флагам.

Ага и + еще и чтобы видеть в родителях источник USE флага - make.conf и настройки /etc/portage/* и системный профиль. Чтобы конкретно было видно источник USE флага.

Если всё дерево до конца, то тут только два выхода:

Если сам граф будет. Кто мешает:

• удалить ненужные слои/зависимости. Т.е. конкретно к примеру выводим зависимости всего мира но обрабатываем исключительно USE флаг gtk+ а не все используемые флаги.
• сохранить его в svg и играться затем?

Т.е. конкретно к примеру выводим зависимости всего мира но обрабатываем исключительно USE флаг gtk+ а не все используемые флаги

Ну я и говорю - нужна интерактивная карта.

сохранить его в svg и играться затем?

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

Неудобно будет.

Удобно или нет… а иначе проследить источник а так же все что он вызывает попросту нет.

Похоже то что нужно PDepGraph.py

PDepGraph generates dependency graph data for being processed in Graphviz.

Но на деле фейлит…