Select provider of libav* libraries

[Andreas Cadhalpun]

Hi Stuart,

On 03.06.2015 11:14, Stuart Prescott wrote:
>> 1: https://wiki.debian.org/Debate/libav-provider/ffmpeg
> 
> thanks for this -- it's good to see a summary of where we are.
> 
> It would be good if you also include information on:

Thanks for the feedback.

>   * the API stability promise of upstream (do we need a library transition 
> each time a minor update is uploaded?)

No API/ABI should ever change with bugfix releases, i.e. 2.6.* releases
all have the same.
With most new major upstream releases 2.* only new API is introduced and
private API/ABI changed. So only buggy programs that use private API
need to be fixed (see e.g. #783879 [1]).
With some new major upstream releases the soversions get increased, at
which point we need a library transition.

>   * assuming there is an API stability promise within each branch, the 
> frequency at which new releases are made that will require transitions

The upstream tracker [2] gives a good overview about this.
The last soversion bumps were:
 * 2.4 (2014-09-14)
 * 2.2 (2014-03-24, only libavfilter)
 * 2.0 (2013-07-10)
 * 1.1 (2013-01-07)
 * 1.0 (2012-09-28, only libavfilter)

So transitions would be about once every half year and if one doesn't count
libavfilter, because it only has a handful of reverse-dependencies, it's
more like once per year.

>   * the detailed plan on how Debian would get from the current packages to 
> these packages. 
> 
> The libav→ffmpeg plan is in various places on this and the debian-release 
> mailing lists, but it would be good to see it in one place for easy 
> reference.

I think the most relevant mail is [3].

> I think we need to see a good overview of:
> 
>   - what source and binary package names will be uploaded to which releases

There are three source packages, whose binaries should be changed to:
 * src:ffmpeg:
   - ffmpeg, ffmpeg-doc, ffmpeg-dbg, qt-faststart
   - lib*-ffmpegN
   - lib*-dev
   - lib*-ffmpeg-dev (transitional, to be removed before stretch release)
   - libav-tools-links (transitional, to be removed after stretch release)
 * src:libav:
   - libav-tools, libav-doc, libav-dbg
   - lib*N
   - libavcodec-extra*
   - lib*-libav-dev
 * src:libpostproc:
   - libpostproc52
   - libpostproc-libav-dev

I have patches implementing these changes, which I plan to send to the BTS
soon.

The uploads will first go to experimental and after passing NEW and getting
a transition slot from the release team, to unstable. 

>   - which binary packages would disappear (and what to do about that)

Short term: none
For stretch: everything still built from src:libav and src:libpostproc and
lib*-ffmpeg-dev.

What we'll do about that is the library transition and what's mentioned
in the point below.

>   - what will be required from maintainers of rdeps

Most will have to do nothing special, only those mentioned in above mail [3]
need to adapt their packages, e.g. change dependencies on libav-tools
to ffmpeg (list in [3]) and drop dependencies on libavcodec-extra
(from devede and dvd-slideshow).

>   - what sort of time periods the transition would take

Well, the actual library transition will probably take about 5 days, which
is the time after which britney propagates the binNMUs to testing.
When it will happen depends on how long NEW processing will take and when
a suitable transition slot is available.
Changing the dependencies/recommends/suggests from libav-tools to ffmpeg
should be done before stretch is released.

>   - the results of the rebuilds you have done

These are available in above mail [3]. blender, mpd and paraview are
resolved in the meantime.

>   - (I'd guess a ben file for the transition tracker would be handy too)

I think the following should work:

title = "ffmpeg";
is_affected = .depends ~ "libavcodec56|libavcodec-extra-56|libavdevice55|libavfilter5|libavformat56|libavresample2|libavutil54|libpostproc52|libswscale3" | .depends ~ "libavcodec-ffmpeg56|libavdevice-ffmpeg56|libavfilter-ffmpeg5|libavformat-ffmpeg56|libavresample-ffmpeg2|libavutil-ffmpeg54|libpostproc-ffmpeg53|libswresample-ffmpeg1|libswscale-ffmpeg3";
is_good = .depends ~ "libavcodec-ffmpeg56|libavdevice-ffmpeg56|libavfilter-ffmpeg5|libavformat-ffmpeg56|libavresample-ffmpeg2|libavutil-ffmpeg54|libpostproc-ffmpeg53|libswresample-ffmpeg1|libswscale-ffmpeg3";
is_bad = .depends ~ "libavcodec56|libavcodec-extra-56|libavdevice55|libavfilter5|libavformat56|libavresample2|libavutil54|libpostproc52|libswscale3";

> I'm aware that the plan is somewhat orthogonal to the actual decision about 
> libav providers but I think the feasibility of the plan also informs us 
> about the feasibility of making the change and gives confidence that the 
> ffmpeg maintainers are aware of the size of the task they are volunteering 
> for.

OK, so I'll try to put this information on the Wiki.

Best regards,
Andreas


1: https://bugs.debian.org/783879
2: http://upstream-tracker.org/versions/ffmpeg.html
3: https://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2015-May/043980.html