Introducing symbol versioning in FFmpeg

[Adam D. Barratt]

Hi,

Apologies for the delay in getting back to you.

On Sun, 2009-12-13 at 09:27 +0100, Reinhard Tartler wrote: 
> We currently FFmpeg version 0.5 in lenny and squeeze. I noticed
> difficulties when trying to update the distro packages to a recent svn
> checkout, because the SONAME of libavutil has been bumped. In situations
> where the application package was not recompiled (yet), this causes
> libavutil to be loaded twice, once with the old SONAME and once with the
> new SONAME.
> 
> My understanding of the situation is that symbol versioning is the
> recommended answer to this problem. I therefore went ahead and started a
> discussion upstream about that [1]. In that discussion, upstream (more
> or less) agreed on that plan.
> 
> I'm proposing the following changes to the FFmpeg packages in Debian:
> 
>  i.   each and every library of FFmpeg applies the following version tag
>       to each and every symbol: ${LIBNAME}_${SONAME}
> 
>  ii.  upload of FFmpeg 0.5 to unstable with versioned symbols
> 
>  iii. binNMU all applications to pick up the new versioned symbols.
> 
>  iv.  Upload a newer FFmpeg snapshot to experimental with versioned
>       symbols.
> 
> I request assistance from the release team for the following questions:
> 
>  - does the symbol versioning strategy in step i. make sense?

Yes.  As a Debian-specific addition, the libraries should have their
shlibs updated to ensure that binaries built against them will have a
">= version_introducing_symbols" dependency.

> I believe so, as upstream does care for ABI compatibility inside the
> single FFmpeg libraries, but not (yet) about issues caused by transitive
> dependencies. E.g., this would mean the symbols of libavutil49 (in
> squeeze) would get the tag LIBAVUTIL_49, whereas libavutil in
> experimental would get LIBAVUTIL_50.
> 
>  - do I need to rename the binary packages and conflict against the old
>    packages as outlined in the last parahraph of the library packaging
>    guide, section 3.3 [2]?

This isn't strictly necessary, although not renaming the packages could
lead to the same kind of issues you mentioned above for partial upgrades
(either testing -> testing or stable -> newstable).

If squeeze and lenny will both have the same soname for each of the
libraries involved, this isn't an issue.

> Upstream has concerns that this is absolutely required due to bugs in the
> gnu linker ld, see his posting in [3].

If I understand correctly, upstream's concerns are around the behaviour
of the linker when multiple versions of the ffmpeg libraries are
available on the system, one with and one without symbol versioning?  If
so then I don't believe that would be an issue for Debian as the
installation of the symbol-versioned libraries would replace the earlier
non-versioned libraries.

> - When would be a good time to do this change? I imagine that depending
>    on the previous answer, this will cause a larger transition for
>    squeeze.

Please go ahead with the uploads introducing symbol versioning.  In
order to ease transition, we'll schedule the required binNMUs once the
package has migrated to testing.

[...] 
> - Currently, FFmpeg exports all sort of internal symbols. With symbol
>    versioning, upstream agreed to limit the list of exported symbols.
>    I'd like to do so in FFmpeg 0.5 in squeeze as well. Do you agree with
>    this?

This would be an ABI breaking change and as such /would/ require a
package name change.  We'd prefer that the symbol versioning change be
made first and then look at the potential impact of the symbol removal.

Regards,

Adam