I'm running into difficulties getting vibrant6 [1] to comply with the
new policy requiring full inter-library dependencies. The source of
the complication is that two of the libraries come in OpenGL and
non-OpenGL variants, but certain intervening libraries are
OpenGL-agnostic and therefore come in only one variant.
Since OpenGL is a pretty hefty dependency, I'd like to avoid it if
possible, and not have the intermediate libraries indirectly require
it; on the other hand, the GL-enabled variant of the higher-level
library (ncbicn3d) specifically needs the GL-enabled variant of the
lower-level library (vibrant) in order to work properly. I would also
like for packages that request linkage against plain vibrant not to
end up depending on the GL variant, even if built on systems with the
GL variant installed. (On the other hand, packages that specifically
try to link against the GL variant should get it)
I haven't quite been able to come up with a reasonable arrangement
that satisfies all of these constraints. The closest I've come up
with so far falls apart the moment ldconfig runs:
BASELINE:
libvibrant-nogl.so.6.1.<date>: real file, soname libvibrant.so.6
libvibrant-nogl.so.6 -> libvibrant-nogl.so.6.1.<date>
[libvibrant-nogl.so -> libvibrant-nogl.so.6.1.<date>]
[libvibrant.so -> libvibrant-nogl.so]
WITHOUT libvibrant6-gl:
libvibrant.so.6 -> libvibrant-nogl.so.6
WITH libvibrant6-gl:
libvibrantOGL.so.6.1.<date>: real file, soname libvibrantOGL.so.6
libvibrantOGL.so.6 -> libvibrantOGL.so.6.1.<date>
[libvibrantOGL.so -> libvibrantOGL.so.6.1.<date>]
libvibrant.so.6 -> libvibrantOGL.so.6 (clobbered by ldconfig :-/)
I could perhaps kludge around this by having libvibrant6-gl also
contain a dummy library with a soname of libvibrant.so.6 that pulls in
libvibrantOGL.so.6 and sorts after libvibrant-nogl.so.6.1.<date>, but
that would be gross, and lead to odd-looking ldd output.
Any suggestions? Should I just punt and force everyone to use the
OpenGL version? (That would certainly be simplest, but I'd really
prefer to avoid the dependency bloat if I can.)
[1] I am simultaneously renaming the package to libvibrant6, so please
refrain from commenting on its archaic name. ;-)
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
