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