[SCM] FFmpeg packaging branch, master, updated. debian/0.5.1-3-4-g4f58b03

[Reinhard Tartler]

On Di, Mai 25, 2010 at 23:22:04 (CEST), Jonas Smedegaard wrote:

> On Tue, May 25, 2010 at 08:59:48PM +0000, siretart at users.alioth.debian.org wrote:
>>The following commit has been merged in the master branch:
>>commit 4f58b031aef85e5f3a0dfac12bbbf1d3ca9bb548
>>Author: Reinhard Tartler <siretart at tauware.de>
>>Date:   Tue May 18 11:07:43 2010 +0200
>>
>>    move presets back to 'ffmpeg' package. Closes #581748
>>
>>    The problem is more serious at it seems. Leaving the presets in
>> /usr/share/ffmpeg will cause file conflicts on the next SONAME
>> bump. brr.
>>
>>    This fix is actually more complicated as it seems. I proposed to
>> change the installation directory to include the soname change.
>> Hower, it did not receive good reception upstream:
>>
>>    http://comments.gmane.org/gmane.comp.video.ffmpeg.devel/109433
>>
>>    In the end, moving it back to the ffmpeg package seems to be the
>> least evil here.
>
> I agree with upstream that it makes little sense shipping with a library
> that does not use it.
>
> How about shipping in an arch-independent package ffmpeg-data?

in principle, yes, that would be an option. I'm however not sure if it
is the smartest. AFAIUI, we should make libavcodec-extra-52 either
depend or recommend it. But depending on it is not possible, as we would
re-introduce #581748 again. Therefore Recommending would work, yes.

But is that really better?

> Then x264 can depend unversioned on that package, and if the data format
> of the files should change some day then x264 can tighten dependency or
> we could add a virtual package name indicating the "soname" of the data
> format.
>
> How does that sound?

the same argument as for not placing them in libavcodec52 can be applied
here as well: neither x264 nor libx264-$SONAME do use these
presets. Only  /usr/bin/ffmpeg uses it, and only if libavcodec was
compiled against it.

Perhaps we should provide an alternate /usr/bin/ffmpeg from the
ffmpeg-extra source package? But would that really solve the problem?

I've been thinking quite a bit about that, but I didn't find a good
solution. This patch leaves the dependencies perhaps a bit too lax, but
at least we avoid upgrade problems when libavcodec's SONAME is bumped.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4