[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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


Reply to: