[FFe] chromium-codecs-ffmpeg for lucid

I very much dislike the idea to get a copy of ffmpeg in. At the very least, I'd like to hear an explicit ok from the security team.

If we don't ship it, tech users will grab it from one of the PPAs, and worse, the vast majority of ubuntu users will just stop using Chromium the first time they hit a <video> and move to the upstream Google Chrome deb which ships the whole thing by default.

BTW, it's not a copy of ffmpeg per say, our system ffmpeg is not multi-threaded.
And Google is taking care of the security of that thing, along with upstream, hence the stack of patches in the tarball.

> I very much dislike the idea to get a copy of ffmpeg in. At the very least, I'd like to hear an explicit ok from the security team.

The security concern feels more like a MIR topic than a motu-release one. The risk for getting release critical bugs is definitly low as we are using this package for ages.

security is a concern for universe as well, and is my main concern.

I've talked to Reinhard (ffmpeg upstream) now, and he told me that security is well maintained for Google's branch.
Also I've been told that the -mt branch will get merged to ffmpeg main at some point, but most probably not for 0.6.

That said, I'm ok to grant the FFe, given that you can convince an archive admin to new the package.

(side note: Reinhard suggested to rename the -nonfree package, since it doesn't contain non-free software. Maybe you could follow suite with the ffmpeg package and name it -extra?).

i meant it as "non-royalty-free" / "non-patent-free", so users know what they may face.
I can use "restricted", but i don't like "extra" as it has a positive aspect.

Of course it has an "positive" aspect because after all, it does offer extra functionality. Our users are not going to be charged for using it. The "risk" is on the distributors side. I strongly oppose package names that indicate ffmpeg would produce non-free or crippled code.

As for security concerns, since google does a good job with mainting their 'fork' security wise, I think we can rely on upstream to provide good security support. Most of the recent security patches came from google anyway, so there is a good chance that chrome's ffmpeg copy gets future security patches earlier than upstream ffmpeg again. For this reason, this embedded copy needs to be considered seperate from the system ffmpeg anyway.

To me, this is more a decision if we want chrome at all, as the ffmpeg part is not the biggest security concern here.

renamed "-extra" but i need to keep a transitional package for the tens of thousands of users who already got it through the PPAs.

thank you very much for this!