Yeah, I wrote a different tool that would take the resulting data structure and output a dot file (see http://www.graphviz.org/ as well as SlackBuilds.org) in an attempt to visualize our java package dependencies.

We had a few hundred of them and many imported other ones; the diagram was not as insightful as I had wished.

Given that most of the slackbuilds packages don't care about each other, you could trim the display quite a bit and perhaps get something interesting.

I just built a new package from your updated source. Works perfectly. I've removed it from my testing-* repositories and moved it directly into the server-* and desktop-* repos, along with the needed pyxdg dependency. I've also made a package for Slackware 14.0.

http://www.microlinux.fr/microlinux/

Here's a little blog post that points to a short HOWTO I've written this morning:

https://kikinovak.wordpress.com/2015...ackbuilds-org/

The THANK YOU note is in the respective ChangeLogs in the repo.

Cheers,

Niki

I think that is broadly right (most packages not related) however I was a bit surprised when testing to find that relationships can spread quite widely. An example from my playing around is speex. It has 12 other packages which directly depend on it; adding other packages which depend on those dependents gives 26 involved packages (including speex itself). If you then feed that result into "hoorex -r" (which tells you all the other packages which those 26 depend on), you end up with 126 altogether. For json-c, the corresponding number are 9, 26 & 65. For lame (which I tried because Niki had been testing with it) the numbers are 9, 62 & 303. I guess they're not huge numbers given there are over 5000 packages in the SBo repo; still I was mildly surprised.

Anyway, back to sorting algorithms, I thought it would be interesting to compare the speed of my fairly primitive sorting code with yours. Hopefully close enough for ordinary use (where there are probably relatively few packages to sort). What about a large input though? To make testing of that a bit easier I've added an option to specify predefined groups of packages instead of having to name each individual package on the command line e.g. "hoorex -g audio system" means to use all the packages in the audio and system categories as input. The big daddy of groups is a special one named "all" so that "hoorex -g all" means to process all the packages in the SBo repo. Now I know what order to build the whole repo in! That calculation takes (mostly) under 3.2secs on my work machine, although I guess there's other stuff going apart from just sorting. Next step is to adapt and swap in your code and test again.

chris

Thanks Niki, I think I retained just enough of my school french to make sense of the blog post and the HOWTO it points to.

I've now added a -g|--group option to compactly specify large numbers of package names without having to explicitly name each one on the command line. Its more cute than useful at the moment so I won't make a new release till there's something more (or a bug fixed).

Actually, if you're putting HooRex into production then I guess testing is finished - I should mark this thread SOLVED and send announcements to the list whenever there's a new version available.

Thanks Niki, and everyone else for testing, comments, code, supportive noises ...

chris

Thank you, Chris, for this nifty little tool.

Niki

guys, let me remind you of this, too:

http://www.linuxquestions.org/questi...rg-4175470545/