While trying in VMs several Slackware derivatives I came across a new package manager called Unified Slackware Package Manager or usm, written by Jay Flood aka Brokenman initially for Porteus but that works on Slackware version 14.1 and presumably on all distributions based on it.

It's young but very promising.

It can be accessed either from the CLI or a GUI (gtkdialog >= 0.8.3 needed for the GUI), and can deal with packages from several repositories, at time of writing:
DISTROS="slackware slackwarepatches slacky salix alien ponce slackonly"

It does everything you would expect but installing or removing the packages (that's your responsibility, isn't it?)[1], can deal with dependencies if you want (I didn't check how yet), and also download and build the packages from http://slackbuild.org.

And, it is very simple to configure and use, so give it a try! There is also a repository on GitHub.

[1]Correction: it doesn't propose to install the packages that it builds, but does for those that it downloads.

Yet another good find for Slackware (no pun intended).

It would be nice, yet it is optional, for Slackware to use any level of dependency tracking. AFAIK only sbotools is capable of doing this using the SlackBuilds .info file descriptors, while others use add-on files not normally used, but that is for from-source builds only. We really don't have anything for binary packages yet unless you look at SalixOS's examples.

Still, Slackware is one of those distributions that you can add-on to nearly endlessly and customize in so many various ways.

1 members found this post helpful.

Of course sqg, shipped in sbopkg, can do that. Check /usr/doc/sbopkg-0.37.0/contrib/sqg if you have it installed.

@All: please try usm before answering. Also to quote Brokenman "This application is in it's infancy and is continually being developed. Suggestions and feedback are most welcome.".

PS I just built sbotools typing "usm -b sbotools"

if you think sqg is stable enough, i can consider to include it on main package on the next release
i have been using it and it's stable enough for me

fascinating what people are doing with bash scripts, ... even if its the wrong tool for the task -imho

2 members found this post helpful.

sqg has been working here flawlessly

Ah the beauty of scripts and scripting.

It behaves as expected as far as I have used it. Of course it can't be more reliable than the <package>.info it relies on.

It wouldn't hurt to have it installed in /usr/bin anyway and that it be more prominently mentioned, as I assume that some folks don't use it just because they are not aware of it and/or it's not in their PATH.

As it is it saves a lot of tedious work so that's worth using it, IMHO.

As for stability I am not sure to know a good definition...

Through usage of ldd, see /usr/share/usm/funcsystemDeps to know more. But again, that is optional.

for dependencies of installed packages you should use sbbdep anyway ;-)

Just transmit you "constructive" criticism to the author. But maybe have a look at the script first...

sorry if you find this was criticism, it was not meant to affect you. and i did ...

I didn't affect me, I just think that feedback about actual usage of usm would be more useful than providing an opinion if we don't know on what it is based.

That said, maybe the dependency resolution provided by sbbdep is better? You just need to elaborate why, and if you do I am sure that Brokenman will welcome your suggestions. He could even integrate it to usm then, who knows?

PS I don't want to trigger another religious war sterile discussion[1] "shell script vs binary", we have had enough of that and I am not Jonathan Swift

[1]Even more useless when the script actually runs a binary...

PPS While we are at it: out of curiosity, did you compare the output and performances of sbbdep with those of depfinder written by George Vlahavas aka gapan?

ldd is a simple but incorrect solution
ldd 'executes' files and give the whole dependency tree including indirect dependencies (A needs B , B needs C), therefore ldd reports A B C.

readelf and objdump give you the real dependencies, without the indirect ones,
but than you have to care about what the linker finds,
this does ldd , so you could use both, and take from ldd only the required ones, but that's than even slower.

you can also simulate the linker behaviour and check where the libs you are looking for are, check things like runpath, rpath infos, and if files have expected sonames.
if you do this you want a cache, like ldd has one,
sbbdep creates also one, and cares about the synchronization of the cache.
that's why it so fast when the cache is available, and it tells you not just what a lib/pkg needs but also who uses a lib/pkg.
you can check the examples to get an idea.

You can reproduce this of course with scripts, but I do not think that this is an easy task and that the result will have a decent performance,

7 members found this post helpful.

Thanks for the find Didier, I'll have to check it out later this week.

I definitely think it shouldn't be buried under the /usr/doc directory. It should be in something that is covered by $PATH. I have been using it since I found out about it (probably a few years) and it's a great addition to sbopkg.