Hello everyone,

Here is a tiny utility script I wrote to help package maintainers visualize packages runtime dependencies as a graph. I wrote that as a programming exercise after Girtablulu asked about a similar thing on IRC.
What it does is reading package information from eopkg and then pull information of every runtime dependency recursively until it reach the end of the graph.

Example for Firefox:

Depending on the use cases, I might extend it, allowing for example visualizing reverse dependencies to determine what can possibly break when doing a rebuild.

Here is the link: https://github.com/guillotjulien/eopkg-graph

P.S It's still rough on the edges, so if you see any bugs / improvements possibilities, feel free to open an issue 😀

    Skyeun This is for spyder3. I was curious to see if there is any repeated dependency.
    If you want to package this here is the package.yml

        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.