searching missing dependencies

wookietreiber kizkizzbangbang at googlemail.com
Fri Feb 4 12:14:55 CET 2011


> Two points to note:
> 
> 1. IIRC 'lvu links' works by using ldd to find any linked-in or linked-to
>    libraries, and therefore will only work with C/C++ like compiled code.
>    I've seen that for Python or Perl modules for example, it doesn't work
>    properly and gives a list of *all* modules that have installed libraries.

I know. Unfortunately one can't find missing
dependencies with non-C/C++ based modules, but the
all-module-output thing can be fixed, I guess.

> 2. Some modules depend on features that could be supplied by one of several
>    other modules, so what shows up on your system might not be the complete
>    story. For example, for your recent 'jasper' submission, you added an
>    optional_depends on %GLUT (i.e. either freeglut or glut) but freeglut
>    conflicts with the mesa-lib that I have on my system with NVIDIA cards.
>    Which begs the question of whether the %GLUT specification is complete.

It wasn't my intention to write a 'solve-it-all'
script. What I wanted to do is figuring out the
current state of linked modules, not what might
be with optional dependencies or aliases.

What 'missing MOD' does is figuring out what MOD
currently links to (by using 'lvu links MOD' which uses
ldd) and check if the linked modules appear anywhere in
the short dependency tree (by using 'lvu stree MOD')
and, if not found, grepping the compile log (by 'lvu
compile MOD') to maybe get some information out of it.

So you can check only the current state, which I
consider really useful before submitting new modules to
find out additional information about what they link to
or depend on.

I will try to write a 'lvu' patch which includes this
feature by e.g. 'lvu missing MOD' or maybe integrate it
in 'lvu links MOD' using a --check-missing option or so.



More information about the Lunar-dev mailing list