JoshStrobl added the From The Community tag .
Showcase: eopkg-deps, a CLI tool for packages runtime dependencies visualization
- Edited
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
- Edited
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 done
- Edited
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
plasma desktop yep looks like fun
Girtablulu How much time it took to generate that?
algent over a min
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):
- Edited
@Skyeun Any reason the install target is /usr/local/bin/?
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
- Edited
Skyeun Solus uses just /usr/bin
This is a fun tool. Thanks.
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.