/home/nand

When packaging, the debhelper (dh_*) tools are both wonderful and awful. Wonderful because they easily handle almost every case, in a very neat way. Awful, because when they don’t work, have a few spare hours ahead!

I’ll share my experience with some private libs, it may be of some help for others. I have a source package that leads to two binary packages. One contains a daemon and some privates libs, the other contains a GUI client. The warnings were “dpkg-shlibdeps: Impossible to find a package for libike.so.2.0.3″ and then “dpkg-shlibdeps: Impossible to find the dependencies of libike”. This would then lead to a missing dependency between the two binary packages.

Ok. Why is it trying to find a package for the lib I am currently building?? The man page was no help. After a few hours of search, I found a notice inviting me to see the dpkg-shlibdeps man page in the very latest version of dpkg-dev. Ah yes, much more clear!

Basically, dpkg-shlibdeps works in two steps. It first list all the required libs for the executables, and then for each lib, it searches to which package it belongs, using dpkg -S and the shlibs files. And here was my problem : I had removed the call to dh_makeshlibs as I thought it was not necessary because the libs are private. But in fact you still have to generate the shlibs files : the debhelper tools will take care to put them in the binary package only if the libs are public.

Yay!