Note that you can make things a bit closer to what you want by using a slightly 
different build sequence:
gclient update -n
cd src
build/gyp_chromium -D use_system_libs=1
This will still checkout a whole bunch of libs, but most of them will not get 
linked in (though it will still link-in giflib as of this moment, 
unfortunately). As a bit of a downside, however, using system version of 
opencv's libhighgui (which we use for I/O routines, not UI) does pull in gtk, 
which isn't a very server'ish dependency at all.

YEAH, I was looking into making this apache module available for the openSUSE 
distribution but all the non-standard build system and the bundled libraries 
make unlikely that I will devout any resources to it.

An standalone tarball with no bundled libraries and a text file that says, "we 
need libraries X , Y, Z version N or later.." and a simple Makefile or 
configure script is enough for distributions, we can figure out the rest by 
ourselves.

Same for Gentoo Linux.
The attempt to create an ebuild is 'sleeping' because the bundled libraries and 
the gclient/svn logic.
A standalone tarball, as judas said - better if released with a version 
tag/number - and deps indications could be helpful.

I've been working on this, and I am at a point where we're almost down to just 
google dependencies being bundled (fixing icu and giflib being included is the 
next step); and I would appreciate if you could perhaps take a look at the 
intermediate step to see if it's moving in the right direction. I am attaching 
a script for tarball generation --- I imagine we will eventually provide the 
sort of tarballs it produces as part of releases.

To use it just do something like:
"./create_distro_tarball.sh modpagespeed.tar.bz2 --svn_path tags/0.9.17.6". It 
will checkout tons of stuff (and throw most of it away) and should eventually 
produce a tarball that's more like the usual expectations. (The tarball will be 
in the /tmp/ directory it gives at the end).

that's a progress :) I currently checking it out, I just want to make a plea to 
google to understand that "the google way" of distributing source code is 
unnaceptable to probably all the distributions.

Im not asking to change your process, just try to be a little more friendly so 
your software can get included. some hints, having:

a) lots of bundled libraries including your owns.
b) a weird, pretty much undocumented,non-standard build system
c) the need of forked libraries

Will certainly discorauge packagers, fundamentally because that is either too 
much work to maintain or the effort of doing so will be worthless as the QA 
teams of the respective distribution will reject such stuff almost instantly.

Hey there, I was curious if there has been any progress on this.  We have an 
environment with non standard Apache paths.  Rolling the current build process 
into an RPM is a bit of a caper.  Thanks!