inter-package shlib deps resolution

[Matthias Klose <doko@cs.tu-berlin.de>]

[cc to debian-devel; I would like to get comments as well]

Aaron Van Couwenberghe writes:
 > Hi all
 > 
 > Is there a standard way for dpkg-genshlibdeps (I think that's its name) to
 > be able to locate dependencies that live in debian/tmp besides
 > superextending LD_LIBRARY_PATH?
 > 
 > IE a package has two libraries in it, libfoo.so and libbar.so. libbar
 > depends on libfoo, but dpkg-genshlibdeps errors because libfoo can't be
 > found in LD_LIBRARY PATH -- any way to deal with this?

Not sure, if this is the right way, but it works for me (using
debhelper extracts):

Assume you build two binary packages foo and bar from one source.
foo has a library libfoo.so.1 and bar a binary bar, which depends on
the freshly built shared library.

In the build target you have to make sure, that the bar binary get's
linked against the built libfoo.so.1, not an installed one. Some
upstream package do this, but others don't. For the second case, you
can do:

	$(MAKE)
	<remove wrongly linked bar binary>
	<make sure, that libfoo.so.1 and libfoo.so are in <dir>>
	LD_LIBRARY_PATH=<dir> $(MAKE)

Then in the binary target:

	dh_makeshlibdeps -a # or create {foo,bar}.shlibs yourself

Now, you have to get the dependencies for all binary objects. But
dh_shlibdeps (or dpkg-shlibdeps) cannot find the dependencies (yet).
If dh_shlibdeps find's something about libfoo.so.1, then it get's this 
info from /var/lib/dpkg/info/foo.shlibs, that is from the old
installed library. If there is no library installed you get messages like:

dpkg-shlibdeps: warning: unknown output from ldd on `debian/tmp/usr/bin/bar':
	 `libfoo.so.1 => not found'

Calling LD_LIBRARY_PATH=<dir> dh_shlibdeps doesn't work, you get
messages like

dpkg-shlibdeps: warning: unknown output from ldd on <dir>/libfoo.so.1

Calling LD_LIBRARY_PATH=`pwd`/<dir> (an absolute path) dh_shlibdeps
doesn't work, you get messages like

dpkg: /<pwd>/debian/tmp/usr/lib/libfoo.so.1 not found.

What (IMHO) should work, but still doesn't is to create a file
debian/shlibs.local:

	cat <all shlibs files of my package> > debian/shlibs.local

The dpkg-deb man page mentions this file, that it is read. But calling 
dh_shlibdeps with this file again, doesn't find the libraries (or the
installed libraries).

Combining the two:

	LD_LIBRARY_PATH=`pwd`<dir> dh_shlibdeps -a

produces error messages again, that it cannot find the libraries (as
above), but it works! Yes, it overworks ... Assuming that the bar 
package contains a shared library libbar.so.1, this generates a self
dependency on bar, which needs to be filtered out again by hand.

I think this is the correct way how to do this. If it is, it's too
complicated and should be simplified. To summarize:

When simply calling dh_makeshlibs

- If you do not have installed the shared libraries you are building,
  you don't get the dependency on this shared lib at all.

- If you do have installed the shared libraries from a previous
  version, you get the dependencies from the installed version, not
  the new version. This is a problem, where the 3rd field of a shlibs
  file changes.

To avoid this behaviour, take the approach described here or build one 
time, install the libaries and build a second time. Then the
dependencies should be correct. 

How does the dbuild package handle this? Does it build packages with
shared libraries twice and installs them between the builds?

How many packages are there with such wrong dependencies?