On Sun, Jul 13, 2003 at 12:10:39PM -0500, Steve Langasek wrote:
> Package: libvibrant6-gl
> Depends: whatever, libgl1
> Replaces: libvibrant6
> Conflicts: libvibrant6
>
> (no Provides:)
>
> And in the shlibs for libvibrant6:
>
> libvibrant 6 libvibrant
On Sun, Jul 13, 2003 at 06:51:57PM +0200, Marcelo E. Magallon wrote:
> 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 SON
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...
Steve Langasek <[EMAIL PROTECTED]> writes:
> So to restate, you have two libraries which export similar ABIs, but not
> identical; the GL-enabled version of the library exports additional
> entry points which are only of use to a subset of callers. You want to
> supply distinct .so links for each
On Sat, Jul 12, 2003 at 11:05:54PM -0400, Aaron M. Ucko wrote:
> 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
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 i
6 matches
Mail list logo
