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. 
You seem to have missed that for Chromium we rebuild the current upstream 
releases in stable. Since there're not guarantees for any kind of API stability 
in
the local ffmpeg copy that is obviously not a good idea.

Cheers,
        Moritz


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141002164349.GA4870@pisco.westfalen.local

Reply via email to