LINUX.ORG.RU

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

 , , ,


0

1

Чтоб на выходе прям в формат graphviz да еще и так чтоб со всеми USE флагами т.е. наглядно было бы видно что и кого тянет.

Как то можно или как и всегда нужно велосипедить все самому?

★★★★★

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

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

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

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

init_6 ★★★★★ ()
Последнее исправление: init_6 (всего исправлений: 1)
Ответ на: комментарий от init_6

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

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

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

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

kostik87 ★★★★★ ()
Последнее исправление: kostik87 (всего исправлений: 1)
Ответ на: комментарий от qnikst

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

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

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

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

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

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

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

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

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

ok.

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

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

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

init_6 ★★★★★ ()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

init_6 ★★★★★ ()

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

PDepGraph generates dependency graph data for being processed in Graphviz.

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

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