Re: problem setting up interlibrary dependencies
"Marcelo E. Magallon" <mmagallo@debian.org> writes:
> Let me sketch something for you...
>
> Package: libvibrant6
> Depends: whatever
>
> Package: libvibrant6-gl
> Depends: whatever, libgl1
> Provides: libvibrant6
> Replaces: libvibrant6
> Conflicts: libvibrant6
Hm... more likely
Package: libvibrant6
Depends: libvibrant6-nogl|libvibrant6-gl, ...
Package: libvibrant6-nogl
Depends: libvibrant6 (= ${Source-Version})
Conflicts: libvibrant6-gl
Package: libvibrant6-gl
Depends: libvibrant6 (= ${Source-Version})
Conflicts: libvibrant6-nogl
given the common GL-neutral libs (without which there would be no problem).
> That works with either of the -dev libraries. The resulting binary
> works with either library.
However, with your scheme, if you build it on a system with
libvibrant6-gl installed, it will end up depending on that package,
even though it would actually work fine with either version of the
library.
> there's a certain assumption about upstream not being of the "it's
> binary forwards compatible" persuassion (what happens if upstream
> decides to introduce a new function call but not modify the SONAME --
> hint, think versioned provides).
I have generally had to bump the minimum shared library version
requirement with each upstream release, but the arrangement I gave
above would handle that, as would Steve's suggestion of generating
OR-ed dependencies.
> Question: does upstream make a distinction at the link-line level if
> the library has or hasn't OpenGL support? It's important for
> compatibility with other distributions.
Yes; the convention is that you link against -lvibrantOGL rather than
-lvibrant if you want OpenGL support -- a distinction I would like to
honor if at all possible, so that developers can still build packages
that require only the non-GL variant on systems with the GL variant
installed.
Anyway, the discussion of multiple -dev packages gave me another idea:
libvibrant6-gl-dev could ship the non-GL variants of the libraries in
some subdirectory of /usr/lib that ldconfig ignored, but with bare .so
symlinks from /usr/lib:
libvibrant6:
/usr/lib/libncbidesk.so.6.1.20030421
/usr/lib/libncbidesk.so.6 -> libncbidesk.so.6.1.20030421
...
libvibrant6-nogl:
/usr/lib/libvibrant.so.6.1.20030421
/usr/lib/libvibrant.so.6 -> libvibrant.so.6.1.20030421
(actively preserved by ldconfig)
...
libvibrant6-gl:
/usr/lib/libvibrantOGL.so.6.1.20030421
/usr/lib/libvibrantOGL.so.6 -> libvibrantOGL.so.6.1.20030421
(actively preserved by ldconfig)
/usr/lib/libvibrant.so.6 -> libvibrantOGL.so.6
(passively preserved by ldconfig -- no competition)
...
libvibrant6-gl.shlibs:
libvibrant 6 libvibrant6 (>= 6.1.20030421)
libvibrantOGL 6 libvibrant6-gl (>= 6.1.20030421)
...
libvibrant6-gl-dev:
/usr/lib/libvibrant-nogl/libvibrant.so.6.1.20030421
/usr/lib/libvibrantOGL.so -> libvibrantOGL.so.6.1.20030421
/usr/lib/libvibrant.so -> libvibrant-nogl/libvibrant.so.6.1.20030421
...
It's kind of hackish, but I think it might actually have a chance of
working; please let me know if you see any problems with it (aside
from unconventionality).
> HTH,
Yes, thanks; it got me thinking about the effects of multiple -dev
packages.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger amu@monk.mit.edu (NOT a valid e-mail address) for more info.
Reply to: