Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Andreas Cadhalpun]

On 29.07.2014 21:59, Raphael Geissert wrote:
> On Tuesday 29 July 2014 18:43:17 Andreas Cadhalpun wrote:
>> On 29.07.2014 09:47, Raphael Geissert wrote:
>>> Andreas Cadhalpun wrote:
>>>> According to the changelog[1], there have been 8 security updates for
>>>> ffmpeg in squeeze.
>>>
>>> There would have been more
>>
>> You're right, my calculation is slightly flawed.
>
> That was my point, so please don't use it as an argument.

Maybe I didn't make my point clear enough, for which the actual number 
of the security uploads is not important, only the order of magnitude.

Given the amount of software in Debian and thus the amount of security 
fixes necessary for a stable release, I think that the additional 
stable-security uploads for FFmpeg in the order of 10 per release will 
be hardly noticeable.

While I understand and agree with the general idea of reducing code 
duplication, I have a really hard time trying to understand why the 
security team has such a strong opposition to the idea of having both 
FFmpeg and Libav in Debian stable.

One argument against code duplication is the risk that security issues 
get fixed in one, but not in the other. But in this particular case 
FFmpeg upstream merges all security fixes from Libav, so an FFmpeg 
package in a stable release won't have that problem.

What is particularly hard for me to understand is why e.g. MySQL and 
MariaDB can be in testing at the same time without much resistance from 
the security team, but FFmpeg and Libav can apparently not.

>>> Not to mention that some bugs that are being
>>> fixed are, for example, for incomplete checks - checks that don't exist
>>> in the 0.5 branch.
>>
>> What do you mean here? If the affected code is not there, then that's
>> nice, because a backport is not needed.
>
> Let me rephrase it: the fix is for an incomplete check, but in 0.5 the check
> is missing - while the rest of the code is there. Which is kinda... worse.

Now I see, what you mean. Indeed that's worse, but if one notices 
something like that, then the whole check can be backported instead of 
the change in the check.
Though it probably would have been better to backport already the 
incomplete check, when it was introduced in the development branch.

Best regards,
Andreas