reopen 360968 reopen 343476 severity 360968 important merge 360968 343476 thanks
> Matthias, > > This is a duplicate of Bug#343476. sorry, merged. > I'm closing this as the > package upstream has decided to not change the location of the libs. > Please see the other bug for their email and mine. But the .pc don't add the runtime path, so running binaries linked against these libraries will fail. Before you change that: > They are stored in an unusual place to avoid any potential for > namespace collisions in /usr/lib on 10 varieties of Unix. even KDE now stores these shared libraries in /usr/lib, so that should be possible for graphviz as well. And Debian doesn't have to cope with "10 varities of Unix". If you look at packages.debian.org, there are no conflicting files in Debian currently. Looking at the list: libagraph.so.2 libcdt.so.2 libexpr.so.2 libgraph.so.2 libgvc.so.2 libgvc_builtins.so.2 libgvgd.so.2 libpack.so.2 libpathplan.so.2 please consider changing the sonames to use a common "gv" prefix, i.e. libgvexpr.so.2 instead of libexpr.so.2. The old *.so names could continue to exist in the private directory. that should even be possible for upstream. libgvplugin_dot_layout.so.2 libgvplugin_neato_layout.so.2 libgvplugin_usershape_gd.so.2 These seem to be used internally by graphviz, so these probably can stay in the private libdir. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
