Actually in concept that doesn't sound too difficult, but I'm sure it would be hard to get the details and "edge cases" right.

It would also have to be recursive in the event the script calls other scripts. slackpkg is ~500 lines and pkgtool is ~700, I don't think it'd be a huge chore to skim them.

HeHe, I use a patch from RH for bash which will make it list all the bins/scripts called by a script. Very handy indeed -even if it may miss certain constructs. The patch itself is really quite small and non-invasive in that it simply expands the '-n' option to print out the called programs. Any fedora/RH source archive of bash will have the patch in there. I filter/sort the results to get a list of unique calls.

1 members found this post helpful.

Dependency is universally defined thus: if A needs B to function, then B is a dependency for A.
It matters not if A or B are scripts or binaries or shared objects.
Simply put: if you are missing 'sed' or 'awk' then probably 'network-scripts' will not work.

I'm not a programmer and have no skills to build such a tool.
As for analyzing shell scripts to find their dependencies, already did that here.

The OP wants to build a dependency resolver and asked for input.
I was just point out to him that the existing tools and lists do not take into account the dependencies of 'shell script packages' and it would be a good thing if some future tool or list did it.
Just giving input, as asked by the OP

Generally speaking, yes. But as the OP mentioned in the thread's title "ldd-based", the post you quoted highlights that there are dependencies that ldd can't detect, thus have to be dealt with other tools or methods (if they are in the scope).

The biggest issue is that ldd detects too many dependencies, i.e. indirect ones. A binary may be linked to several shared objects, and ldd will also report the shared objects that those link to in turn. If the purpose is to find what might need recompiling after a shared library bumps its version number, you really only want to report the direct dependencies to avoid a lot of needless recompiles.

For this purpose, "readelf -d" is a better source of dependency information than "ldd".

6 members found this post helpful.

Indeed. depfinder uses ldd, but its purpose is to find all packages needed to run the programs included in a given package, thus it has to find the dependencies recursively.

But of course to find which dependencies you need to recompile for a shared library's version bump in -current, readelf -d is better. As an end user I didn't come across a missing dependency so far in a full Slackware installation, so thanks ;-)

and this is why sbbdep does read the elf information plus handling and emulating linker search path correct, including all properties, that ones found in the elf dyn section like rpath dynpath + relative path handling and resolving of the HOME location plus respecting the system properties, to find the used libraries and the alternatives. (plus a hidden option to handle some special cases that developers might have) And having a cache to get those info as fast as possible, and not just tell you what a binary/library needs, but also who is needing a library. self plug done ;-)

1 members found this post helpful.