On Sun, Jul 13, 2003 at 11:30:43AM -0400, Aaron M. Ucko wrote:
> Right. I would moreover like for the GL variant to supersede the
> non-GL variant when both are installed, since that's what the
> GL-neutral higher-level libraries will be linking against.
Let me sketch something for you...
Package: libvibrant6
Depends: whatever
Package: libvibrant6-gl
Depends: whatever, libgl1
Provides: libvibrant6
Replaces: libvibrant6
Conflicts: libvibrant6
Package: libvibrant-dev
Depends: whatever, libvibrant6
Package: libvibrant-gl-dev
Depends: whatever, libvibrant6-gl, libgl-dev
Provides: libvibrant-dev
Replaces: libvibrant-dev
Conflicts: libvibrant-dev
How does this look on the filesystem?
Package: libvibrant6
/usr/lib/libvibrant.so.6.0.0
/usr/lib/libvibrant.so.6 -> libvibrant.so.6.0.0
Package: libvibrant-dev
/usr/lib/libvibrant.so -> libvibrant.so.6
Package: libvibrant6-gl
/usr/lib/libvibrant.so.6.0.0
/usr/lib/libvibrant.so.6 -> libvibrant.so.6.0.0
Package: libvibrant-gl-dev
/usr/lib/libvibrant.so -> libvibrant.so.6
The NEEDS of libvibrant6's libvibrant.so.6:
libc.so.6
libsomething.so.1
libanother.so.2
The NEEDS of libvibrant6-gl's libvibrant.so.6:
libc.so.6
libsomething.so.1
libanother.so.2
libGL.so.1
The shlibs for libvibrant6:
libvibrant 6 libvibrant6
The shlibs for libvibrant6-gl:
libvibrant 6 libvibrant6-gl
Now let's compile something:
gcc -c doesntneedGL.c
gcc -o doesntneedGL doesntneedGL.o -lvibrant
That works with either of the -dev libraries. The resulting binary
works with either library. What about needsGL.c?
gcc -c needsGL.c
gcc -o needsGL needsGL.o -lvibrant
That will work only if libvibrant-gl-dev is installed. The resulting
binary will only work if libvibrant6-gl is installed.
Now there's a package that needs to make sure it won't be compiled with
the GL variant (for whatever reason):
Build-Depends: libvibrant-dev
Build-Conflicts: libvibrant-gl-dev
Does that satisfy your needs? Note that I have simply ignored your
(implicit) request for a solution that let's you install libvibrant6
and libvibrant6-gl at the same time. I have also made the assumption
that libvibrant's API is sane (and ABI likewise). This solution
depends on knowledge about the innerworkings of dpkg-shlibdeps _and_
the GNU linker _and_ the Linux dynamic linker. Note furthermore that
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).
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.
HTH,
Marcelo
