Devin Carraway <debian@devin.com> [2002-09-22 01:35:32 -0700]: BTW, I wanted to also say... > I know of three ways to deal with this one -- add a new path to > ld.so.conf (yuck), Blech! Very yucky taste in mouth. ;-) > link with -rpath, or wrap the apps in a script which alters > $LD_LIBRARY_PATH. None of these are thrilling; I gather that rpath > is verboten, but haven't found any mention of it in the policy > manual. Undesireable for many reasons. For example I can't use the same binary for two different installations. > The wrapper script approach seems the least problematic, but since the > libs are in the package and the script would hardcode the path it > doesn't seem inherently any better than -rpath. The wrapper script is the most palatable of the yucky tasting solutions. It allows a postinst script to customize the paths in the wrapper script without needing to recompile the binary. Which allows installation in non-expected locations such as /install_root/usr/ and things like that. It also allows some non-compile solutions such as manual hacking of the script to make problem installations work. You should be thinking about non-traditional installations of your package. If you can avoid those shared libraries it would be best. Libraries should be either shared in /usr/lib or not shared at all. The halfway between place is not a mature methodology at this time and contains many problems. Bob
Attachment:
pgpUncynA8Ssm.pgp
Description: PGP signature