algent The reason you don't see repeated dependencies is probably because I had a bug in my code 😅. I was not adding edges to the graph when the dependency was already used elsewhere, resulting in a tree being generated instead of a graph. Here is a test I did with kio after fixing:

Seeing how unreadable it is, I'll work on an alternative interactive HTML renderer, and I'll probably add a flag to limit the recursivity depth.

Beware that this is quite heavy on the CPU and the RAM

      Skyeun The reason you don't see repeated dependencies is probably because I had a bug in my code

      Can you use that bug as a feature, by adding a flag for edges.

          algent Hum, probably, but I'll need to determine rules to determine to which node attach my repeated dependency. For example, with dracut, glibc is pulled by almost all the dependency tree, so do I attach my glibc node with dracut, or with kmod or with xz, etc.

          Example (this is generated using a new flag that display single nodes):

            More out of habit than anything else. And also checking around what others precognise since there is so much folders to choose from:

            /usr/local/bin is for normal user programs not managed by the distribution package manager, e.g. locally compiled packages. You should not install them into /usr/bin because future distribution upgrades may modify or delete them without warning.
            https://unix.stackexchange.com/a/8658

              Now I understand why people were asking about adding graphing to eopkg-deps the other day.

              Just as an FYI, I'm planning on replacing eopkg-deps with a ypkg specific tool because it misses a lot of things that are only builddeps. It'll still probably rely on the eopkg index for runtime dependencies since pspec doesn't list those out for package.yml managed packages and ypkg itself assumes that system.base and system.devel are installed while it is running.