Patch to sort out libgstreamer0.9 versioning

[Loïc Minier]

        Hi,

On Mon, Sep 12, 2005, Rob Taylor wrote:
> Some the handling of internal dependencies against libgstreamer0.9-0 in
> gstreamer0.9 seemed slightly messy and caused an error from lintian. I'm
> not sure of the reasoning for the current setup but the following patch
> seems to maintain the desired functionality and cleans this working up.

 Ok, this is what I feared, you're reverting the double-dependency I
 have added a couple of revisions ago, IIRC:

    * Add a versioned dependency with >= current-upstream-version to all
      current shlibs inter-dependencies to ensure consistency of symbols to
      avoid things such as #315556.
      [debian/control, debian/control.in, debian/rules]

 There are two types of dependencies:
 A/ shlibs dependencies as classically pulled by other apps or plugins
    via usage of the API, and the binary links between the ELF elements,
    ie the ABI for symbols exposed in the API
 B/ internally hidden dependencies such as usage of symbols outside of
    the API or functional conventions that one can not describe via C
    functions or headers ("call function init() prior to calling foo()")

 The shlibs system is enough for applications built with GStreamer's API
 (ie. build-dependig on the -dev packages).  The shlibs system is also
 needed for the binaries in the GStreamer packages themselves, because
 they rely on other libs, this is all type A/.

 But upstream makes an assumption within binaries built from the same
 source: things built from the GStreamer source may use internal symbols
 and may rely on certain functional conventions, these are type B/
 dependencies.

 Type A/ dependencies are the classical ones, and I'll bump the soname
 and shlibs when needed (for example I'll bump shlibs when new functions
 are added to the API, and change the soname if some are removed).  This
 might or might not happen at all for an upstream release.

 Type B/ dependencies force me to have a dependency between all binary
 packages generated from the same source on the depended on binary
 packages at the exact same source version, for all upstream releases.

 I hope this makes the issue clear to you, and why I need to list the
 same dependency too times for different reasons.

   Bye,

-- 
Loïc Minier <lool at dooz.org>
Come, your destiny awaits!