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

[Reinhard Tartler]

On Mi, Mai 26, 2010 at 05:06:52 (CEST), Felipe Sateler wrote:

> On Tue, May 25, 2010 at 18:10, Reinhard Tartler <siretart at tauware.de> wrote:
>> 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.
>
> I don't see the problem with the current approach, if I understood
> upstream correctly. If the files are _parsed_ by ffmpeg, then the
> binary is the one that depends on the files. Thus the files belong in
> the binary package. If the current libavcodec does not have x264
> support then there is only a small waste of bandwidth and storage
> space. ffmpeg will depend on the latest libavcodec anyway, wouldn't
> it?

no, ffmpeg will depend on a 'matching' libavcodec. With an alternative
dependency on the 'main' libavcodec (without libx264 wrapper) and the
'extra' variant (with the libx264 wrapper).

> Hmm, but as you note on the upstream thread, if libavcodec-extra lags
> behind then there is a problem... but that is a problem independent of
> whether the files are bundled with ffmpeg or libavcodec.

Putting them in libavcodec-extra avoids the presets getting out of
sync. We have 2 possibilities to get out of sync: 

 a) libavcodec's libx264 wrapper <-> ffpresets
 b) ffmpeg <-> ffpresets

upstream argues that b) might happen as well, but in my experience, only
a) has happened so far. The current solution (have the presets again in
the 'ffmpeg' package) effectively addresses b), but not a) sufficiently.

well, maybe it is best if we consider this as a weird corner case and
just move on.

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