[Evolution] pkg-has-shlibs-control-file-but-no-actual-shared-libs

[Loïc Minier]

On Sun, Jan 11, 2009, Yves-Alexis Perez wrote:
> E: evolution-plugins-experimental:
> pkg-has-shlibs-control-file-but-no-actual-shared-libs
> E: evolution-plugins:
> pkg-has-shlibs-control-file-but-no-actual-shared-libs
> and some warnings:
> W: evolution: unused-shlib-entry-in-control-file
> liborg-gnome-evolution-hula-account setup
> W: evolution: unused-shlib-entry-in-control-file liborg-gnome-bogo-junk
> plugin
> W: evolution: unused-shlib-entry-in-control-file liborg-gnome-calendar
> file
> W: evolution: unused-shlib-entry-in-control-file
> liborg-gnome-evolution-startup wizard
> W: evolution: unused-shlib-entry-in-control-file liborg-gnome-calendar
> http
> W: evolution: unused-shlib-entry-in-control-file liborg-gnome-groupwise
> features
> […]
> 
> It seems that's because of the DEB_DH_MAKESHLIBS_ARGS_* stuff in
> debian/rules. I guess the intention is to add the correct dependency on
> evolution for evolution-plugins-* but it doesn't seem to really be the
> correct way.

 Right, I think this broke.  dh_makeshlibs allows generating shlibs
 which are used to generate dependencies on a shared library.  evolution
 is a "shared binary", but we wont get any shlibs support for that;
 plugins are real shared libraries, but nothing depends on them;
 finally, /usr/lib/evolution/2.*/*.so are real shared libraries, but not
 in the library path.

 I think the intent was to cover the third type of objects to generate
 dependencies on evolution for the plugins using evolution's libs.

 e.g. /usr/lib/evolution/2.22/plugins/liborg-gnome-face.so is in
 evolution-plugins and uses evolution libs such as
 /usr/lib/evolution/2.22/libevolution-smime.so.0.

 Unfortunately, this probably broke with the dpkg-shlibdeps rewrite; I
 suspect dpkg-shlibdeps will now insist that *.so be in the library
 search path to add them to shlibs.

 Try appending /usr/lib/evolution/2.22 to LD_LIBRARY_PATH, and it should
 fix shlib generation and fix this subtle construct.  It should be in
 the env of both dh_makeshlibs -pevolution and dh_shlibdeps -pevolution,
 -pevolution-plugins and others.  I think DEB_SHLIBDEPS_INCLUDE only
 covers dh_shlibdeps, not dh_makeshlibs.

 The --noscripts are correct because we want shlibs but we don't want
 ldconfig calls (as ldconfig doesn't see this dir anyway).

-- 
Loïc Minier