[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#360968: graphviz libs should be stored in /usr/lib.

	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 

	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 

  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

	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,

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

Reply to: