[SCM] FFmpeg packaging branch, master, updated. debian/0.5.1-3-4-g4f58b03
siretart at tauware.de
Tue May 25 22:10:52 UTC 2010
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:
>>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:
>> 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
> 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.
Reinhard Tartler, KeyID 945348A4
More information about the pkg-multimedia-maintainers