Patch to sort out libgstreamer0.9 versioning

Rob Taylor robtaylor at
Mon Sep 12 17:30:02 UTC 2005

I meant to reply on-list...

On Mon, 2005-09-12 at 17:17 +0200, Loïc Minier wrote:
>  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.

The point of this patch is where the outcome of A) satisfies B), then
you don't need the depends for B. Obviously the schema you have in place
makes a lot of sense where you have dloadable binaries produced by the
same source package, as these internal dependencies won't be picked up
by dh_shlibdeps.

let me illustrate: 
this bug fix meant that the dependencies of gstreamer0.8-misc went from 
(trimmed to the relevent ones):
libgstreamer-gconf0.8-0 (>= 0.8.0), libgstreamer-plugins0.8-0 (>=
0.8.0), libgstreamer0.8-0 (>= 0.8.9-1)


libgstreamer-gconf0.8-0 (>= 0.8.0), libgstreamer-plugins0.8-0 (>=
0.8.0), libgstreamer0.8-0 (>= 0.8.10-1), libgstreamer-gconf0.8-0 (>=
0.8.10), libgstreamer-plugins0.8-0 (>= 0.8.10)

I'm proposing that the better fix would be to produce dependencies of:

libgstreamer-gconf0.8-0 (>= 0.8.10), libgstreamer-plugins0.8-0 (>=
0.8.10), libgstreamer0.8-0 (>= 0.8.10-1)

by judicious use of -V,

Does that make sense, or is there a further subtlety I am missing?


Rob Taylor

More information about the Pkg-gstreamer-maintainers mailing list