Hi Joey,

(log edited for brevity)

<Robot101> walters: how do I stop cdbs from running dh_makeshlibdeps on all the packages?
<Robot101> walters: it's false-positivey on Gaim's plugins, leading to extraneous calls to ldconfig
<walters>   * dh_makeshlibs: only scan files matching *.so.* and *.so, not *.so*.
<walters>     Closes: #204559
<walters> Robot101: does that fix it?
<Robot101> walters: no
<Robot101> walters: they are .so files, but they're in /usr/lib/gaim/. plugins, not shared libs.
<Robot101> but anyway, I have DEB_DH_MAKESHLIBS_ARGS := -plibgaim-remote0 -V
<Robot101> so it should only be doing libgaim-remote anyway
<Robot101> or am I missing something?
<Robot101> I could always do DEB_DH_MAKESHLIBS_ARGS_gaim := --no-act
<Robot101> but that's fucking evil :D
<walters> Robot101: hmm.  the plugins are in both packages?
<Robot101> walters: there are three packages, gaim, libgaim-remote0 and libgaim-remote-dev
<Robot101> gaim has /usr/lib/gaim/*.so, plugins. libgaim-remote0 has libs in /usr/lib
<walters> Robot101: i see.
<walters> Robot101: hm, well, maybe dh_makeshlibs should only look at .so files in /usr/lib and /lib, not /usr/lib/packagename
<walters> (would that break anything?)
<vorlon> nothing in Debian should be allowed to link to libs in /usr/lib/packagename, really, so probably not.
<walters> joeyh: ayh?
<calc> it would break packages which are still buggy
<Robot101> W: gaim: postinst-has-useless-call-to-ldconfig
<Robot101> W: gaim: postrm-has-useless-call-to-ldconfig
<Robot101> see what lintian does to find that error
* calc coughs about something that is probably buggy ;)
<Robot101> lintian checks to see if files are put in any of these directories: lib, usr/lib, usr/lib/libg++-dbg, usr/X11R6/lib/Xaw3d, usr/local/lib, usr/X11R6/lib, usr/lib/libc5-compat, lib/libc5-compat

The bug walters reported on my behalf gets more interesting still. The
particular false positive that I encountered occurs because of this
(continuing the pasting IRC log theme, in case you didn't get it on IRC):

<Robot101> joeyh: aha, found the bug
<Robot101>                elsif ($objdump=~m/\s+SONAME\s+(.+)-(.+)\.so/) {
<Robot101>                         # idiotic crap soname format
<Robot101>                         $library=$1;
<Robot101>                         $major=$2;
<Robot101>                 }
<Robot101> this matches a plugin called gaim-remote.so
<Robot101> with name gaim and major remote
<Robot101> leading to a shlibs entry of "gaim remote gaim"

Either this regexp needs tightening up, or dh_makeshlibs should be made
more selective about where it looks, as suggested in the original bug.
I'm not sure which is better at the moment.

Regards,
Rob

Colin Walters wrote:

This has come up before, and I am reluctant to put such a nasty list in
debhelper and maintain it.

Can't you use dh_makeshlibs -X?

reassign 204975 debhelper
merge 204975 205142
thanks

[I wasn't CC'd on the discussion here, just seeing it now]

Well, Policy §8.1.1 explicitly lists a set of directories.  So
if you just mirror that, it should be OK.

clone 205142 -1
retitle -1 could section 8.1 mandate what library directories will be searched by ldconfig, rather than just describing what they currently are
reassign -1 debian-policy
thanks

Policy 8.1 lists a set of directories for shared libraries, but it lists
it as a non-normative aside and footnote. It seems to me that ldconfig
could change its behavior w/o violating this policy, or something could
stick a new line in /etc/ld.so.conf. Indeed, things do put lines in
there, and it's not clear if policy requires ldconfig be run for
libraries in such directories or not.

Also, the list of directories in the footnote does not match those in
ls.so.conf on my (sid) system. /usr/X11R6/lib/Xaw3d is long gone.

If policy was authoratative about this, I'd not mind putting the list in
debhelper, but when it's just descriptive, I risk having to track
everything that could change the list myself, which is not a position I
want to be in.

Reassigning to policy. :-)