#204975 cdbs: postrm and postinst have useless call to ldconfig

#204975#5
Date:
2003-08-11 16:34:35 UTC
From:
To:
I've switched to cdbs for file-roller debian package.  But after building I've these two warnings :

W: file-roller: postinst-has-useless-call-to-ldconfig
W: file-roller: postrm-has-useless-call-to-ldconfig


file-roller has a so file "/usr/lib/bonobo/libfile-roller-component.so", but according to lintian :

"The postinst script calls ldconfig even though no shared libraries are
installed in a directory controlled by the dynamic library loader."


/usr/lib/bonobo is not "controlled by the dynamic library loader", so the call is useless.

#204975#14
Date:
2004-10-11 17:34:01 UTC
From:
To:
tags 204975 +patch
thanks

 Feel free to test this attempt at implementing the recommendations of
 the Policy.

   Regards,

#204975#21
Date:
2004-10-11 18:25:30 UTC
From:
To:
I do not like this approach, because it makes the package build
dependant on the contents of ld.so.conf. Since various packages modify
that file, there's no canonical list of what directories are used, and
changing behavior based on the contents of the file is asking for
trouble. The other alternative, noted in #205142, of hard-coding the
list of directories from policy into debhelper, is better, but still not
appealing.

Loïc Minier wrote:

#204975#26
Date:
2004-10-12 08:46:50 UTC
From:
To:
Joey Hess <joeyh@debian.org> - Mon, Oct 11, 2004:

 A lot of things are build dependents, and I think you believe it could
 cause vicious build-conflicts.
   I think you should look at Policy 8.1.1, because there is no such
 list of directories.  You're guaranteed to have /lib and /usr/lib, but
 you *must* run ldconfig when you add to directories listed in
 /etc/ld.so.conf.

 I believe there's no harm in running ldconfig on systems where the list
 of directories is different.  If you think there is, I suggest you
 change the patch I've sent to hardcode the list instead of loading it
 from /etc/ld.so.conf, and you'll have to make sure you update your
 list.

   Regards,

#204975#31
Date:
2004-10-25 12:07:07 UTC
From:
To:
Joey Hess <joeyh@debian.org> - Mon, Oct 11, 2004:

 Here's your hardcoded list.

   Regards,

#204975#44
Date:
2016-09-30 00:42:59 UTC
From:
To:
Another approach is to find out from ldconfig which directories it is
searching - you can tell it to use a different file instead of
/etc/ld.so.conf (e.g. /dev/null in this example) if you don't want to
change behaviour based on the contents of that file (and files it
includes):

$ /sbin/ldconfig -N -X -v -f /dev/null 2>/dev/null|sed 's,^\(/.*\):\( (.*)\)\?$,\1,p;d'
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
/lib
/usr/lib

Cheers,
    Olly

#204975#49
Date:
2016-10-02 12:08:35 UTC
From:
To:
Hi,

Re-reading this bug – filed 12 years ago – I have to agree with Joey Hess (and I find my own tone from 12 years ago pretty bad, sorry about that!): it’s not a good idea to rely on the contents of /etc/ld.so.conf.

It’s less big a deal than it used to be because of /etc/ld.so.conf.d/* which is where other packages would change the search path, but it’s still an issue because an admin might have changed the local config and this will affect package builds.
sed -n '/^\//s#:$##p’
(match lines leading with slash, remove trailing colon and print them)

However it might be worth bringing this discussion to Debian Policy as this currently said that /etc/ld.so.conf contents must be used.
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-ldconfig <https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-ldconfig>

Another perhaps smarter approach would be to do away with postinst requirements entirely by installing a ldconfig file-based trigger in libc for *.so files under interesting directories. This would let libc define when to run libc’s ldconfig rather than having each shared library package carry a build-time and install time snippet…

Cheers,
- Loïc Minier

#204975#54
Date:
2016-10-02 12:25:00 UTC
From:
To:
Loïc Minier:
directories. This would let
library package carry a

At the current time, we have migrated to activation triggers.  They are
still in each package, but it does avoid the shell snippets (and all the
related prerm+postinst scripts).

As for using a path trigger, I believe that was ruled out as they are
recursive.  The libc-bin package would have to declare an interest in
*all* of /usr/lib, which will generate tons of false-positives.  I
suspect it may also be a bit heavy on the dpkg side.

Thanks,
~Niels

#204975#59
Date:
2016-10-02 12:51:53 UTC
From:
To:
Indeed, it seems one has to specify a dir or specific file and one can not use a regexp.

https://anonscm.debian.org/cgit/dpkg/dpkg.git/tree/doc/triggers.txt <https://anonscm.debian.org/cgit/dpkg/dpkg.git/tree/doc/triggers.txt>

- Loïc Minier