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

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

>  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

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:

        /usr/lib/libncbidesk.so.6 -> libncbidesk.so.6.1.20030421

        /usr/lib/libvibrant.so.6 -> libvibrant.so.6.1.20030421
            (actively preserved by ldconfig)

        /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)

        libvibrant    6 libvibrant6    (>= 6.1.20030421)
        libvibrantOGL 6 libvibrant6-gl (>= 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

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: