Patch to sort out libgstreamer0.9 versioning

[Rob Taylor]

Pulling this back onlist, my fault it's fallen off ;)

On Tue, 2005-09-13 at 09:39 +0200, Loïc Minier wrote:
>         Hi,
> 
> On Tue, Sep 13, 2005, Rob Taylor wrote:
> > Let me restate this situation in simplified logical form to try to
> > convince you. dependencies are an AND relation, so logically the case
> > i'm trying to simplify is equivalent to:
> > (V>=A) AND (V>=B)
> 
>  Correct.
> 
> > where A (e.g. 0.9.1) < B (e.g. 0.9.1-1)
> 
>  Correct *for the current version*.

no, this is always true without loss of generality where A and B are not
identical.

any situation where A!=B will have either A>B, or B<A (as versioning is
totally ordered), if B<A, simply rename the variables, and the argument
holds.

> > so the only case where [ (V>=A) AND (V>=B) ] does not give the same
> > outcome as [ (V>=B) ] is where  V>=A and V<B. Given that version numbers
> > are fully ordered and A <B as already stated, this is an impossible
> > situation.
> > Hence where A<B, [ (V>=A) AND (V>=B) ] is logically equivalent to (V>=B)
> 
>  Correct for *now* and for inter-dependencies only.
> 
>  I - shlibs do not apply to gstreamer alone, other apps are affected, so
>  you just can't replace it by blindly looking at inter-dependencies in
>  gstreamer alone.
> 
>  II - now, 0.9.next comes out, and I don't have to bump shlibs, but I bump
>  inter-deps because of some type B deps changes.  With your model,
>  everyone get the shlibs pain.
> 
>  (in other words: A := >= 0.9.next, and B != >= 0.9.1-1, but in your
>  example A would be used for type B deps, and B for type A debs (shlibs))

The above argument only makes sense to me if packaging system and katie
transitions consider dependencies generated by shlibdeps differently
somehow. I don't believe this is the case, i could be wrong of course...


Thanks,
Rob Taylor