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

[Felipe Sateler]

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?
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.




-- 

Saludos,
Felipe Sateler