Hello, Stephen. I had problems lately linking to graphviz, and I found that your simple solution is to add an rpath to every program that links with graphviz. Your reasons are: ================================================================== From bug #312533: They are stored in an unusual place to avoid any potential for namespace collisions in /usr/lib on 10 varieties of Unix. LD_LIBRARY_PATH is not recommended as it is a royal-pain for the user. Instead I recommend use of --rpath Using pkgconfig you can set this up with: CFLAGS=`pkg-config libgvc --cflags` -Wall -g -O2 LDFLAGS=-Wl,--rpath -Wl,`pkg-config libgvc --variable=libdir` `pkg-config libgvc --libs` ================================================================== From bug #343476: It is standard behavior for package developers who install many libraries to place them in package-specific subdirectories under /usr/lib. This was done intentionally. This is not an error with the graphviz package. ================================================================== Sorry, Michael, but it is a bug. First of all, due to an arbitrary decision by your side, you are forcing the rest of Debian to use --rpath where it should be avoided at all (even lintian shouts about it). As Matthias Klose said, the shared libraries should go into /usr/lib. Please stop reciting the 'avoid any potential for namespace collisions in /usr/lib on 10 varieties of Unix' mantra. This is Debian, not 10 varieties of Unix. This is all about *integrating*, not simple packaging. If KDE did, you can. Your argument is as valid as: 'Upstream wants to install it in /opt/usr/lib in order to avoid collisions'. If you still think that you are sticking to Policy, I quote you the most prominent part about this issue: -------------------------------------------------------------------------------- From Policy, section 8.1: If your package includes run-time support programs that do not need to be invoked manually by users, but are nevertheless required for the package to function, then it is recommended that these programs are placed (if they are binary) in a subdirectory of `/usr/lib', preferably under `/usr/lib/'<package-name>. If the program is architecture independent, the recommendation is for it to be placed in a subdirectory of `/usr/share' instead, preferably under `/usr/share/'<package-name>. -------------------------------------------------------------------------------- Your libraries are not run-time support programs. -------------------------------------------------------------------------------- From Policy, section 10.2: Shared object files (often `.so' files) that are not public libraries, that is, they are not meant to be linked to by third party executables (binaries of other packages), should be installed in subdirectories of the `/usr/lib' directory. Such files are exempt from the rules that govern ordinary shared libraries, except that they must not be installed executable and should be stripped.[5] Packages containing shared libraries that may be linked to by other packages' binaries, but which for some _compelling_ reason can not be installed in `/usr/lib' directory, may install the shared library files in subdirectories of the `/usr/lib' directory, in which case they should arrange to add that directory in `/etc/ld.so.conf' in the package's post-installation script, and remove it in the package's post-removal script. -------------------------------------------------------------------------------- From the first paragraph: Your libraries *are* public libraries, sorry. From the second paragraph: 'avoid any potential for namespace collisions in /usr/lib on 10 varieties of Unix' is not a _compelling_ reason. In fact, our system does not have any conflict with graphviz, as Matthias said, and if so, we will notice very fast. I am considering to raise the severity of this bug to 'grave', given that graphviz-dev does not work for anyone as is. If you aren't still buying this argument, we can forward this issue to Technical Committee, but I hope that will not be necessary. Best regards, Ender. -- Vous au moins, vous ne risquez pas d'être un légume, puisque même un artichaud a du coeur. -- Amélie (Le fabuleux destin d'Amélie Poulain). -- Desarrollador de Debian Debian developer
Attachment:
pgpdnmZAAc9R1.pgp
Description: PGP signature