What would you like to be added:
The ability to list the specific shared lib dependencies for a binary. For example:

$ readelf -d ./partx

Dynamic section at offset 0x1c908 contains 29 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libblkid.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libsmartcols.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000c (INIT)               0x4000
 0x000000000000000d (FINI)               0x15304
 0x0000000000000019 (INIT_ARRAY)         0x1d530
...

We could specifically note that there are shared lib dependencies: libblkid.so.1, libsmartcols.so.1, and libc.so.6

These files could be cross correlated with other packages that provide these files to discover relationships between packages and files (or files and files if there is no representative packaging metadata available). We can additionally discover other shared libs and do the same analysis, in which case we can build a tree of dependencies for executables.

The missing part of this is being able to reconcile runtime attributes that may change the structure of the tree (such as LD_LIBRARY_PATH). However, as long as the files are present the superset of dependencies can be created without issue (no need to consider these runtime constraints).

There is a lot more thought needed here; does this imply a separate binary cataloger? are those findings considered packages? if they are not (thus considered only files) how do you keep extra binary format info around? or do we only focus on creating relationships between files? does this overlap with the golang bin cataloger or is it in a separate-enough of a domain?