Showcase: eopkg-deps, a CLI tool for packages runtime dependencies visualization

Skyeun

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 😀

algent

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

JoshStrobl

You know there's already an eopkg-deps, right? It's even in the repo. 😛

https://github.com/DataDrake/eopkg-deps

Skyeun

JoshStrobl Damn, forgot to check first! Time for me to rebrand I guess 😅 It'll now be known as eopkg-graph, resulting in the graph command being renamed into generate. Here is the new link: https://github.com/guillotjulien/eopkg-graph. Can my first post be edited?

Skyeun

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

Girtablulu

Skyeun done

algent

Skyeun Ok, packaging this again. 😃

algent

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.

Girtablulu

plasma desktop yep looks like fun

algent

Girtablulu How much time it took to generate that?

Girtablulu

algent over a min

Skyeun

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):

davidjharder

@Skyeun Any reason the install target is /usr/local/bin/?

Skyeun

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

davidjharder

Skyeun Solus uses just /usr/bin

This is a fun tool. Thanks.

DataDrake

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.