Dear Release Team,
I'm in the process of implementing symbol versioning for the FFmpeg
library. This work is done in coordination with upstream, but as FFmpeg
is a rather complex set of libraries, this (probably) needs to be done
in coordination with the Debian Release Team as well.
Short recap: FFmpeg ships the following set of libraries (internal
dependencies in brackets):
- libavutil:
- libavcodec: (libavutil)
- libavformat: (libavcodec, libavutil)
- libavfilter: (libavcodec, libavutil)
- libavdevice: (libavformat, libavcodec, libavutil)
- libpostproc: (libavutil)
- libswscale: (libavutil)
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?
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]?
Upstream has concerns that this is absolutely required due to bugs in the
gnu linker ld, see his posting in [3].
- 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.
Moreover, FFmpeg has introduced a policy of naming all publicly exported
functions 'av_*', and all internally exported functions 'ff_*'. However,
there are some additional symbols known that are used by application
packages. These need to be exported additionally of course, but it is
not obvious which of these symbols are actually used. So my last request
for assistance:
- 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?
[1] http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/100196
[2]
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id293373
[3] http://article.gmane.org/gmane.comp.video.ffmpeg.devel/100664
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
