| 1 |
On Mon, Apr 30, 2012 at 1:30 PM, Mike Frysinger <vapier@g.o> wrote: |
| 2 |
> On Monday 30 April 2012 12:32:35 Matt Turner wrote: |
| 3 |
>> On Mon, Apr 30, 2012 at 12:11 PM, Mike Frysinger wrote: |
| 4 |
>> > On Monday 30 April 2012 12:00:59 Rich Freeman wrote: |
| 5 |
>> >> doing it wrong. I don't like how Google develops Android in the dark, |
| 6 |
>> >> or that they bundle 1GB of third-party stuff in their Chromium source |
| 7 |
>> >> and distribute a favored binary-only derivative. |
| 8 |
>> > |
| 9 |
>> > err, they distribute a Chromium source tarball, and their build system |
| 10 |
>> > includes flags to use the system versions of those bundled libs if you so |
| 11 |
>> > choose. i think this is a perfectly fine compromise. |
| 12 |
>> |
| 13 |
>> It looks like chromium-20.0.1115.1.ebuild removes 45 bundled |
| 14 |
>> libraries |
| 15 |
> |
| 16 |
> to be sure the system ones get used |
| 17 |
> |
| 18 |
>> and still has TODOs in place to use the system's ffmpeg, |
| 19 |
>> hunspell, (Open?)SSL, SQLite, and libvpx. |
| 20 |
> |
| 21 |
> it's on going work :). ffmpeg/libvpx are a bit harder as Chromium syncs faster |
| 22 |
> than they make releases i believe. |
| 23 |
> -mike |
| 24 |
|
| 25 |
Right. Generally, the bundled ffmpeg does not correspond to an |
| 26 |
official upstream release. |
| 27 |
|
| 28 |
ffmpeg upstream is not afraid of making API changes, so it has proven |
| 29 |
quite difficult to make chromium work with all versions on ffmpeg in |
| 30 |
portage, plus the bundled snapshot. When we were using the system lib, |
| 31 |
it would break nearly every time a new major version of chromium was |
| 32 |
forked. |
Archives