Patch to sort out libgstreamer0.9 versioning
robtaylor at floopily.org
Tue Sep 13 08:42:37 UTC 2005
Pulling this back onlist, my fault it's fallen off ;)
On Tue, 2005-09-13 at 09:39 +0200, Loïc Minier wrote:
> 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)
> > 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
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
> > 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...
More information about the Pkg-gstreamer-maintainers