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.
tags 204975 +patch thanks Feel free to test this attempt at implementing the recommendations of the Policy. Regards,
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:
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,
Joey Hess <joeyh@debian.org> - Mon, Oct 11, 2004: Here's your hardcoded list. Regards,
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
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
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
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