[FFmpeg-devel] Upgrade Trouble

[Uoti Urpala]

On Sun, 2009-12-06 at 20:03 +0100, Michael Niedermayer wrote:
> On Sun, Dec 06, 2009 at 11:50:21AM +0200, Uoti Urpala wrote:

> > and it's better to do that
> > for all FFmpeg libraries in one go.
> 
> What is better will be decided by the ffmpeg developers and of course
> Reinhard who actually does the work and who might run into problems
> with one approuch and thus find the other preferable at that point,
> now he did already run into a problem with stuff moved from lavc->lavf
> maybe there are other problems with the alternative, we will see ...

As I just explained in the mail you're replying to, the symbol move
(lavf->lavc, not lavc->lavf btw) caused problems when retroactively
adding symbol versioning to an FFmpeg version _before_ the move and then
testing update to new FFmpeg version from after the symbol move. This is
NOT a reason to avoid adding symbol versioning to current FFmpeg unless
another move is expected to happen soon and for some reason can't be
handled in a way that would avoid the problems.


> > Symbol versioning _will_ be needed
> > for lavc/lavf too at latest at the next version bump (as there are other
> > libraries depending on them),
> 
> maybe but even if it is so that is so since many years and no reason to
> introduce versioning in lavc in the same revission as lavu.

Yes the issue has existed for years (though has become more important
over time as the number of packaged libraries using FFmpeg has
increased). But what difference does that time make? I don't see any
reason why it'd be an argument not to version lavc/lavf.


> > and introducing the new versions smoothly
> > requires that everything has been built with versioning support _before_
> > the new lavc/lavf versions appear.
> 
> Again this is not correct, applications never need to be rebuild
> 
> old soname libavutil needs a rebuild due to a bug in the gnu linker
> which causes a versioned dependancy to be linked to a unversioned
> definition even though a correctly versioned definiiton is available.
> [this bug should be reported]

Even if you want to rely on the linker to get the right result for
applications without explicit versioning that changes very little.
Rebuilding multiple packages is still needed, and it's still better to
do it for all of lavc/lavf/lavu at once. After the next incompatible
lavc/lavf change, introducing the new versions smoothly still requires
that versioned libraries have already been available _before_ the change
and things have already been rebuilt against them.