[SOLVED] Testing of HooRex (SlackBuilds.org dependency calculator)
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Testing of HooRex (SlackBuilds.org dependency calculator)
Could people please test a new dependency calculator please? I'd appreciate any comments, bug reports etc., prior to a proper release. Its at https://github.com/cwilling/hoorex
It started out as a way to find out which SBo packages would be affected by a change to one package in particular e.g. if package "speex" changes, which other packages might be affected? Simplistically, the answer is found by determining all the SBo packages which list speex in the REQUIRES field of their .info file. A "find" command run over a local copy of the SBo repo will give an answer. However that answer needs some human interpretation - it is no good, the way it is, as input to some other script that I may want to use. Also, that answer only gives a single "level" of packages which require speex. Surely (possibly, at least) there will be other packages which depend on that first load of dependent packages. Who knows how long the trail of dependencies may be? HooRex answers this question (and others).
hoorex speex
will return a list of packages which name speex as a direct dependency (they list speex in their .info file). Running:
hoorex -m speex
will return an extended list of dependent packages i.e. it also includes packages which depend on the first level of dependents, also packages which depend on the dependents' dependents etc., etc.
The output is always listed in "build order" i.e. it works as a queue that you could supply to some build tool. You can specify multiple packages to resolve just by adding their names to the command line. A -l (--long) option includes the SBo package category in the output making it easier to be use in a shell script to automate the building/installation of all the relevant packages. A simple minded example using json-c and speex:
Code:
cd /path/to/slackbuilds
for lpkg in $(hoorex -l speex json-c) ; do
cd $lpkg
pkgname=$(basename $lpkg)
source ./$pkgname.info
wget $DOWNLOAD
sh $pkgname.SlackBuild
installpkg /tmp/$pkgname-$VERSION-*_SBo.tgz
cd -
done
HooRex also resolves dependencies in the traditional way (which is like the reverse of what has been described so far). To know the complete dependency tree in build order for vlc, use the -r option and run:
hoorex -r vlc
All the available HooRex options are shown from:
hoorex -h
and there's a man page too.
The source tarball is available in releases tab of the link above - at the moment, the direct link to it is https://github.com/cwilling/hoorex/archive/0.5.3.tar.gz (use "wget --content-disposition ..." for a fully named tarball). Just run make install (as root) to install the hoorex script (python) and manpage. The pyxdg package (available at SBo) is a run time dependency.
As I already said, I'm looking for comments, bug reports etc., anything to make HooRex more accurate and robust. Thanks for your time.
chris
Last edited by chris.willing; 04-18-2015 at 09:56 PM.
Reason: Mention pyxdg run time dependency
Second and somewhat minor, could there be an option to change the way the output appears, for example, instead of getting the output as a list of space separated packages, could we get it in a newline separated format or a tree-like format so that its easy to visualize the dependencies (-r) of a package...
I've pushed out a 0.5.4 version which contains the enhancements suggested by aaditya, along with fixes for some minor bugs I found along the way. Any more feedback would be greatly appreciated.
I've pushed out a 0.5.4 version which contains the enhancements suggested by aaditya, along with fixes for some minor bugs I found along the way. Any more feedback would be greatly appreciated.
Thanks for testing the changes you suggested aaditya.
BTW something similar to what you tested as above (first find who requires gtkmm, then find build order for one of them) can be done using a hoorex pipeline - it feeds output of first hoorex instance as input to a second hoorex instance e.g.
Code:
hoorex -i gtkmm | hoorex -r -1
which finds who (that you have installed) requires gtkmm and then displays a build order for _all_ of them - not just build order for gpartd. Of course, if you want to view the individual build order(s) then you would have to do it as you already did.
Thanks again for your suggestions - restricting output to packages already installed is very useful.
this is great. Is there a way for it to distinguish between packages installed from SlackBuilds.org and those from other sources?
On first use, hoorex builds and saves an index of dependency relationships by walking through a local copy of your slackbuilds repository (which we presume you already downloaded by git, rsync etc.). That process uses the REQUIRES field of each package's .info file. In a sense, this restricts things to SBo packages. When hoorex checks its "raw" output against packages already installed, it uses the directory listing at /var/log/packages - those packages could be from anywhere (but contain no dependency information themselves).
Something I have in mind (and partially implemented already) is to enable the initial index building to use something other than the REQUIRES field of the .info files. Some people already enhance their local .info files with additional build requirements to suit how they like particular packages built. This can be done by adding to the existing REQUIRES field; however this leads to lots of additional work when merging SBo updates (pretty much weekly, recently). I personally add an extra field PREREQS at the very end of the .info file. In the PREREQS field, I add whatever additional packages I want along with $REQUIRES e.g.
Code:
PREREQS="$REQUIRES foo bar"
This keeps intact REQUIRES field intact so git merges are mostly seamless.
The reason to go through all that is to suggest that the current hoorex mechanism to index the dependencies of an SBo repo may be adaptable to other repositories. Provided those other repos have a consistent strategy for registering dependency information, hoorex could probably parse them too. Do you have a particular "other" source in mind?
chris
Last edited by chris.willing; 04-20-2015 at 07:08 PM.
Reason: typo
Well, yes and no. I didn't explicitly change it (so looks like I forgot) but, as ponce already found, it is set correctly at build/install time via the Makefile.
Its interesting you noticed that in the first place - you must be reading the code. Hope there's nothing too ugly in there ...
This looks like a very interesting and useful project. I'm curious: why the name HooRex?
Finding project names can be difficult, as I think you've experienced recently yourself
HooRex is a corruption of "who requires", so that running 'hoorex gtkmm' is like asking 'who requires gtkmm'. I guess it makes packages seem to have some human aspect; maybe 'what requires ..." would be more accurate but whatrex (or wotrex) doesn't roll off the tongue quite as well. I hope it doesn't mean something awful in french ...
chris
Last edited by chris.willing; 04-20-2015 at 07:06 PM.
Reason: typo
Well if you're going to take the approach of having what you call a 'cache', you'd be better off using a proper sqlite database -- then your complex queries are just trivial SQL. And then you can keep all sorts of other useful things in there.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.