Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Gentoo Development (http://www.linux-archive.org/gentoo-development/)
-   -   Chromium bundled code (http://www.linux-archive.org/gentoo-development/661441-chromium-bundled-code.html)

Rich Freeman 04-30-2012 04:28 PM

Chromium bundled code
 
On Mon, Apr 30, 2012 at 12:11 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Monday 30 April 2012 12:00:59 Rich Freeman wrote:
>> doing it wrong. *I don't like how Google develops Android in the dark,
>> or that they bundle 1GB of third-party stuff in their Chromium source
>> and distribute a favored binary-only derivative.
>
> err, they distribute a Chromium source tarball, and their build system
> includes flags to use the system versions of those bundled libs if you so
> choose. *i think this is a perfectly fine compromise.

Must be a fairly new compromise - but glad to hear that they've come
along a bit.

Maybe their future Google Earth install package for Linux won't bundle wine. :)

In any case, I think this really just gets to my point - people who
develop FOSS aren't doing it with the express goal of making your life
difficult - they just don't always have the same itches. If you help
them out or ask NICELY sometimes they'll even help scratch yours.

Rich

Matt Turner 04-30-2012 04:32 PM

Chromium bundled code
 
On Mon, Apr 30, 2012 at 12:11 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Monday 30 April 2012 12:00:59 Rich Freeman wrote:
>> doing it wrong. *I don't like how Google develops Android in the dark,
>> or that they bundle 1GB of third-party stuff in their Chromium source
>> and distribute a favored binary-only derivative.
>
> err, they distribute a Chromium source tarball, and their build system
> includes flags to use the system versions of those bundled libs if you so
> choose. *i think this is a perfectly fine compromise.
> -mike

It looks like chromium-20.0.1115.1.ebuild removes 45 bundled
libraries, and still has TODOs in place to use the system's ffmpeg,
hunspell, (Open?)SSL, SQLite, and libvpx.

Mike Frysinger 04-30-2012 05:30 PM

Chromium bundled code
 
On Monday 30 April 2012 12:32:35 Matt Turner wrote:
> On Mon, Apr 30, 2012 at 12:11 PM, Mike Frysinger wrote:
> > On Monday 30 April 2012 12:00:59 Rich Freeman wrote:
> >> doing it wrong. I don't like how Google develops Android in the dark,
> >> or that they bundle 1GB of third-party stuff in their Chromium source
> >> and distribute a favored binary-only derivative.
> >
> > err, they distribute a Chromium source tarball, and their build system
> > includes flags to use the system versions of those bundled libs if you so
> > choose. i think this is a perfectly fine compromise.
>
> It looks like chromium-20.0.1115.1.ebuild removes 45 bundled
> libraries

to be sure the system ones get used

> and still has TODOs in place to use the system's ffmpeg,
> hunspell, (Open?)SSL, SQLite, and libvpx.

it's on going work :). ffmpeg/libvpx are a bit harder as Chromium syncs faster
than they make releases i believe.
-mike

Mike Gilbert 04-30-2012 05:42 PM

Chromium bundled code
 
On Mon, Apr 30, 2012 at 1:30 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Monday 30 April 2012 12:32:35 Matt Turner wrote:
>> On Mon, Apr 30, 2012 at 12:11 PM, Mike Frysinger wrote:
>> > On Monday 30 April 2012 12:00:59 Rich Freeman wrote:
>> >> doing it wrong. *I don't like how Google develops Android in the dark,
>> >> or that they bundle 1GB of third-party stuff in their Chromium source
>> >> and distribute a favored binary-only derivative.
>> >
>> > err, they distribute a Chromium source tarball, and their build system
>> > includes flags to use the system versions of those bundled libs if you so
>> > choose. *i think this is a perfectly fine compromise.
>>
>> It looks like chromium-20.0.1115.1.ebuild removes 45 bundled
>> libraries
>
> to be sure the system ones get used
>
>> and still has TODOs in place to use the system's ffmpeg,
>> hunspell, (Open?)SSL, SQLite, and libvpx.
>
> it's on going work :). *ffmpeg/libvpx are a bit harder as Chromium syncs faster
> than they make releases i believe.
> -mike

Right. Generally, the bundled ffmpeg does not correspond to an
official upstream release.

ffmpeg upstream is not afraid of making API changes, so it has proven
quite difficult to make chromium work with all versions on ffmpeg in
portage, plus the bundled snapshot. When we were using the system lib,
it would break nearly every time a new major version of chromium was
forked.

"Paweł Hajdan, Jr." 05-03-2012 09:34 AM

Chromium bundled code
 
On 4/30/12 6:32 PM, Matt Turner wrote:
> On Mon, Apr 30, 2012 at 12:11 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>> On Monday 30 April 2012 12:00:59 Rich Freeman wrote:
>>> doing it wrong. I don't like how Google develops Android in the dark,
>>> or that they bundle 1GB of third-party stuff in their Chromium source
>>> and distribute a favored binary-only derivative.
>>
>> err, they distribute a Chromium source tarball, and their build system
>> includes flags to use the system versions of those bundled libs if you so
>> choose. i think this is a perfectly fine compromise.

Right, and the source tarball is ~175 MB. It's not perfect, but it's
also far from 1 GB. The bundled libraries are included in the tarball.

> It looks like chromium-20.0.1115.1.ebuild removes 45 bundled
> libraries.

Note that the list in the ebuild is about _excluding_ bundled libraries,
i.e. the directories listed are removed and everything else is removed.

I'm generally co-operating with upstream (also as part of that upstream,
but with limited resources at least for now) so that there are options
to use system libraries, and what's left is non-trivial to unbundle
(e.g. mesa) but it should be unbundled at some point.

> and still has TODOs in place to use the system's ffmpeg,
> hunspell, (Open?)SSL, SQLite, and libvpx.

Yes, the TODOs can definitely tell you what's left there. The list is
not comprehensive though.

Ah, and help is always welcome - with unbundling libraries, gcc-4.7
porting, and other things. Feel free to send your thoughts/questions to
chromium@g.o.

Paweł

"Paweł Hajdan, Jr." 05-03-2012 09:37 AM

Chromium bundled code
 
On 4/30/12 7:42 PM, Mike Gilbert wrote:
> ffmpeg upstream is not afraid of making API changes, so it has proven
> quite difficult to make chromium work with all versions on ffmpeg in
> portage, plus the bundled snapshot. When we were using the system lib,
> it would break nearly every time a new major version of chromium was
> forked.

Right. Eventually I'd like to create an ffmpeg compatibility layer in
Chromium, so that all Chromium-specific code would talk to it, and the
layer would know how to handle (at compile time) different versions of
ffmpeg.

Also, the browser binary should really just link directly to ffmpeg
libraries instead of using dlopen. I also plan to change that.

Rich Freeman 05-03-2012 03:28 PM

Chromium bundled code
 
On Thu, May 3, 2012 at 5:34 AM, "Paweł Hajdan, Jr."
<phajdan.jr@gentoo.org> wrote:
>
> Right, and the source tarball is ~175 MB. It's not perfect, but it's
> also far from 1 GB. The bundled libraries are included in the tarball.

I was thinking about the unpacked size - which is 1001M according to
du for chromium-18.0.1025.168.tar.bz2. That's a lot of source code...

However, my whole point wasn't to throw stones at the chromium team -
I think that they've been doing a great job of fixing this problem,
and will continue to do so. I just was pointing out that Google's
practice of bundling dependencies wasn't to my liking, but that I
wasn't going to give them too much of a hard time precisely because
I'm not being part of the solution.

Rich

"Walter Dnes" 05-03-2012 09:39 PM

Chromium bundled code
 
On Thu, May 03, 2012 at 11:28:49AM -0400, Rich Freeman wrote

> However, my whole point wasn't to throw stones at the chromium team -
> I think that they've been doing a great job of fixing this problem,
> and will continue to do so. I just was pointing out that Google's
> practice of bundling dependencies wasn't to my liking, but that I
> wasn't going to give them too much of a hard time precisely because
> I'm not being part of the solution.

I think Chromium's problem is that it's based on Chrome. And Google
is "pulling an AOL" by trying to turn Chrome into an OS for its
Chromebooks. To paraphrase the old emacs joke... Chrom(e/ium) is a
mediocre OS that lacks a lightweight web browser. I just did a
"pretend" build for Chromium. I fail to understand why a *WEB BROWSER*
needs elfutils and dbus and udev as hard-coded dependancies. The udev
dependancy is a show stopper for me, as I've migrated over to mdev. See
https://wiki.gentoo.org/wiki/Mdev That page is now mostly other
people's contributions. I was the rabble-rouser who started it.

--
Walter Dnes <waltdnes@waltdnes.org>

Mike Frysinger 05-03-2012 11:18 PM

Chromium bundled code
 
On Thursday 03 May 2012 17:39:30 Walter Dnes wrote:
> I think Chromium's problem is that it's based on Chrome.

you've got that wrong. Chrome is based on Chromium.

> And Google is "pulling an AOL" by trying to turn Chrome into an OS for its
> Chromebooks.

ChromeOS and Chrome are run as semi-separate projects. the former uses Gentoo
to provide a slim/secure Linux base in which you run Chrome.

> I fail to understand why a *WEB BROWSER* needs elfutils and dbus and udev as
> hard-coded dependancies.

you need to think bigger. Chromium supports joystick inputs (which come and
go) for playing games in the browser, so udev makes sense. it also supports
looking up your location, detecting when the network comes up/down, and
kde/gnome password stores, all of which require dbus. and with nacl, you're
loading ELF objects, so libelf makes sense.

really though, if you don't like Chrome, then don't use it. many people do.
-mike

Luca Barbato 05-04-2012 12:49 AM

Chromium bundled code
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/05/12 16:18, Mike Frysinger wrote:
> On Thursday 03 May 2012 17:39:30 Walter Dnes wrote:
>> I think Chromium's problem is that it's based on Chrome.
>
> you've got that wrong. Chrome is based on Chromium.
>
>> And Google is "pulling an AOL" by trying to turn Chrome into an OS for its
>> Chromebooks.
>
> ChromeOS and Chrome are run as semi-separate projects. the former uses Gentoo
> to provide a slim/secure Linux base in which you run Chrome.
>
>> I fail to understand why a *WEB BROWSER* needs elfutils and dbus and udev as
>> hard-coded dependancies.
>
> you need to think bigger. Chromium supports joystick inputs (which come and
> go) for playing games in the browser, so udev makes sense.

So is it using libudev to get that information? I guess would be
possible to patch it out, probably dbus would cover that base as well.

(As soon I have some time I might dabble with a dbus integration for mdev)

lu

- --

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+jJ5UACgkQ6Ex4woTpDjQOtQCZAYnPNGSZ/qlukltSyLL+zACm
vuYAoJp6uvjatUzQrJRK53Hl9kQD9IiN
=onw7
-----END PGP SIGNATURE-----


All times are GMT. The time now is 07:48 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.