[FFmpeg-devel] [RFC] Internal API updating policy

[Uoti Urpala]

On Sun, 2010-05-16 at 00:25 +0200, Stefano Sabatini wrote:
> On date Sunday 2010-05-16 00:21:05 +0300, Uoti Urpala encoded:
> > This is the part that of your suggested rules that can fail. Suppose
> > lavf major version 1 already uses that symbol, and current lavf version
> > is 2. Both use lavc version 1. Having both lavf1 and lavf2 installed
> > simultaneously must be possible. You can't update lavf1 because there
> > are no newer versions of it, and it would be incompatible with the
> > changed lavc, so it must depend on lavc1 < X.Y.Z. OTOH lavf would depend
> > on lavc1 >= X.Y.Z. Therefore the version of lavc1 installed would need
> > to satisfy both that the version is < X.Y.Z and >= X.Y.Z. This is
> > impossible, so package version constraints aren't enough and a major
> > lavc version bump is required.
> 
> That's because you cannot have two different shared libraries with the
> same major right? If it would be possible to keep two distinct
> libavcodecX.Y.Z and libavcodecX.Y.Z' and make libavformatN and
> libavformatM link against the right one

It's not.

>  then the problem wouldn't exist, right?

Depends on how things would be if they weren't like they are now...


> Well having such a system should help at least for distribution when
> just one version of each shared library needs to be present, at least

It doesn't help much in that case, and that case isn't enough. Packaging
the next major library version must be possible without switching every
depending library and application in a single atomic transition.