Re: Introducing symbol versioning in FFmpeg
Reinhard Tartler wrote: > On Mi, Jan 27, 2010 at 19:52:35 (CET), Adam D. Barratt wrote: > >> On Wed, 2010-01-27 at 07:54 +, Adam D. Barratt wrote: >>> http://release.debian.org/~adsb/ffmpeg_binNMUs.txt is what I believe to >>> be the list of packages potentially needing binNMUs. >>> >>> Excluding those packages which have either had sourceful uploads in the >>> past day or so (e.g. vtk) or have already scheduled or completed binNMUs >>> for python2.6 (e.g. picard) would be useful to avoid duplicated work and >>> builds. >> The list has now been updated to remove those packages which have had >> rebuilds since the ffmpeg upload or have outstanding python2.6 binNMUs >> scheduled for them (and in one case to include a binNMU for one >> architecture where the python2.6 binNMU completed shortly before ffmpeg >> was available on that architecture). > > I guess you are already on it: ffmpeg has transitioned now to testing, > so the binNMUs can be scheduled now. binNMUs are being scheduled. Cheers Luk ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Introducing symbol versioning in FFmpeg
On Wed, 2010-01-27 at 07:54 +, Adam D. Barratt wrote: > http://release.debian.org/~adsb/ffmpeg_binNMUs.txt is what I believe to > be the list of packages potentially needing binNMUs. > > Excluding those packages which have either had sourceful uploads in the > past day or so (e.g. vtk) or have already scheduled or completed binNMUs > for python2.6 (e.g. picard) would be useful to avoid duplicated work and > builds. The list has now been updated to remove those packages which have had rebuilds since the ffmpeg upload or have outstanding python2.6 binNMUs scheduled for them (and in one case to include a binNMU for one architecture where the python2.6 binNMU completed shortly before ffmpeg was available on that architecture). Regards, Adam ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Introducing symbol versioning in FFmpeg
On Tue, 2010-01-26 at 07:57 +0100, Reinhard Tartler wrote: > On Mo, Dez 21, 2009 at 23:17:42 (CET), Adam D. Barratt wrote: > > > 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. > > While ffmpeg not migrated to testing yet (will most probably do so in 2 > days), it has now been installed on all architectures: > > https://buildd.debian.org/status/package.php?p=ffmpeg&suite=unstable > > AFAIUI binNMUs for reverse depends can be scheduled now. It would be preferable to have the package migrate first to avoid the (albeit low) possibility of anything that needs to migrate quickly getting stuck behind it; admittedly a few recent uploads, including a couple of python2.6 binNMUs, appear to have picked up updated ffmpeg dependencies already. In any case, ffmpeg should migrate in tonight's britney run. > Do you have > specialized tools for determining a list of packages subject to binNMUs, > or shall I compile a list for i386? http://release.debian.org/~adsb/ffmpeg_binNMUs.txt is what I believe to be the list of packages potentially needing binNMUs. Excluding those packages which have either had sourceful uploads in the past day or so (e.g. vtk) or have already scheduled or completed binNMUs for python2.6 (e.g. picard) would be useful to avoid duplicated work and builds. Regards, Adam ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Introducing symbol versioning in FFmpeg
On Mo, Dez 21, 2009 at 23:17:42 (CET), Adam D. Barratt wrote: > 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. While ffmpeg not migrated to testing yet (will most probably do so in 2 days), it has now been installed on all architectures: https://buildd.debian.org/status/package.php?p=ffmpeg&suite=unstable AFAIUI binNMUs for reverse depends can be scheduled now. Do you have specialized tools for determining a list of packages subject to binNMUs, or shall I compile a list for i386? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Introducing symbol versioning in FFmpeg
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
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
