Bug 461912 – net-libs/webkit-gtk - split up into separate packages

• Product: Gentoo Linux
• Status: RESOLVED UPSTREAM

[Description Raymond Jennings 2013-03-16 09:47:01 UTC]

Is there a way to make webkit-gtk have a smaller footprint?

Perhaps by splitting it up into multiple component libraries?

it takes a HUGE amount of time to compile and link, and also has a pretty hefty virtual memory footprint

Reproducible: Always

Actual Results:  
webkit is huge

Expected Results:  
webkit broken into pieces

if this is the wrong place to raise this, a suggestion on where else to go would be appreciated

[Comment 1 Gilles Dartiguelongue (RETIRED) 2013-03-29 23:48:55 UTC]

sorry but webkit-gtk is mostly one library, not something we can split at distribution level easily. The problem lies in the way upstream builds this library and it can only be solved by working with upstream to leverage the different issues that lead to this problem which is no way simple.

[Comment 2 Raymond Jennings 2013-03-30 10:26:10 UTC]

I just had an interesting chat with upstream on freenode:

[2013-03-30 02:58:16 -0700] <jzmer> is webkitgtk+'s font fall back mechanism fontconfig-conformant?
[2013-03-30 02:58:29 -0700] <jzmer> or is it supposed to be fontconfig-conformant?
[2013-03-30 02:58:43 -0700] <jzmer> i have come across multiple cases wherein it is not
[2013-03-30 03:05:52 -0700] * jzmer has quit (Quit: WeeChat 0.4.0)
[2013-03-30 03:09:59 -0700] <spyro> so what would the first step be in breaking up wkgtk so it can be built ieasier?
[2013-03-30 03:11:07 -0700] <plaes> spyro: on Gentoo side it would be having two slots for webkit1 and webkit2
[2013-03-30 03:11:16 -0700] <plaes> and webkit1 would have gtk2 and gtk3 slots :P
[2013-03-30 03:11:48 -0700] <spyro> that does sound like a very large improvement.  Why, is gentoo globbing them all together in one big giant lump?
[2013-03-30 03:12:30 -0700] <plaes> because it requires at least two days of work from me :P

[Comment 3 Gilles Dartiguelongue (RETIRED) 2013-04-10 14:32:50 UTC]

yes but that's about the only thing we can do.

Maybe we should have webkit-gtk or webkit1-gtk for webkit1 with slot 2 and 3 for each gtk respectively and webkit2-gtk for webkit2. But not sure it will help much as building webkit2 reuses some objects from webkit1 and those are not splittable into a separate package by themselves afaik.

The biggest issue in fact is that webkit-gtk is just a few huge .so libraries really.

[Comment 4 Raymond Jennings 2013-04-10 18:52:05 UTC]

can't that just make webkit2 depend on webkit1?

I don't consider it a small problem that full debug info fails to build on a 32-bit environ.  I'm stuck with economy hardware and I don't have a huge budget for 64-bit.

Plus bulky object files are just a major pain on the vm subsystem.