FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 04-30-2012, 04:28 PM
Rich Freeman
 
Default 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
 
Old 04-30-2012, 04:32 PM
Matt Turner
 
Default 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.
 
Old 04-30-2012, 05:30 PM
Mike Frysinger
 
Default 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
 
Old 04-30-2012, 05:42 PM
Mike Gilbert
 
Default 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.
 
Old 05-03-2012, 09:34 AM
"Paweł Hajdan, Jr."
 
Default 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ł
 
Old 05-03-2012, 09:37 AM
"Paweł Hajdan, Jr."
 
Default 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.
 
Old 05-03-2012, 03:28 PM
Rich Freeman
 
Default 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
 
Old 05-03-2012, 09:39 PM
"Walter Dnes"
 
Default 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>
 
Old 05-03-2012, 11:18 PM
Mike Frysinger
 
Default 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
 
Old 05-04-2012, 12:49 AM
Luca Barbato
 
Default 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-----
 

Thread Tools




All times are GMT. The time now is 09:25 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org