Hi Moritz, On 02.10.2014 18:43, Moritz Mühlenhoff wrote:
On Wed, Oct 01, 2014 at 04:32:24PM +0200, Andreas Cadhalpun wrote:However, I can understand why one embedded code copy is better than one embedded code copy plus a library in addition to it.This would be understandable, yes. There are now two options: a) Let FFmpeg migrate to testing and make chromium use it. b) Don't let FFmpeg migrate and let chromium continue to use the embedded copy, in spite of the policy violation. If this really would be preferred, then the FFmpeg libraries and tools could be build from the chromium source package, because that can't increase the security workload, as the source is already in wheezy.Chromium is actually a special case. It's a huge monster package which is very difficult to integrate and maintain.
One of the reasons that make it difficult to integrate is that it embeds many other projects. (The third_party folder in the chromium source tree contains 150 subfolders!) From chromium's debian/rules one can see that the chromium maintainers try to use system libraries wherever possible, e.g. for bzip2, libjpeg, libpng and so on. It also already contains (outdated) support for using system FFmpeg libraries, but using that was not possible, because FFmpeg hadn't been available in Debian since squeeze until very recently. So I hope the maintainer of chromium is now happy to be able to use more system libraries.
You seem to have missed that for Chromium we rebuild the current upstream releases in stable.
I was aware of that and as I understand it, this is not something the security team likes very much.
Since there're not guarantees for any kind of API stability in the local ffmpeg copy that is obviously not a good idea.
Great that we agree on b) being no good idea. So can we now go forward with a) by letting FFmpeg migrate to testing? Best regards, Andreas