Bug#602316: Packaging mod_pagespeed for Debian

[Jeff Kaufman <jefftk@google.com>]

It looks like most of the discussion above has been based around
packaging mod_pagespeed's standard build-from-source flow, which pulls
in its dependencies over the network.  There's also an alternate
distribution method, however, in the form of a source tarball:
https://dl.google.com/dl/linux/mod-pagespeed/tar/beta/mod-pagespeed-beta-1.11.33.4-r0.tar.bz2

It builds against some system libraries:
     apr, aprutil, apache httpd headers, icu, libjpeg_turbo, libpng,
openssl, zlib

Other dependencies are included in the tarball, but could be replaced
with existing debian packages:

    closure_library -> libclosure-compiler-java

    gflags -> libgflags2v5

    giflib -> libgif7
       mod_pagespeed would probably need changes to handle giflib 4.1.x -> 5.1.x

    google-sparsehash -> libsparsehash-dev

    jsoncpp -> libjsoncpp1

    libwebp -> libwebp6

    modp_b64 -> libmodpbase64-0

    optipng -> optipng
       we'd need to make a shared library package or something, since
the current
       package is a CLI tool and mod_pagespeed needs opng_reduce_image() etc

    protobuf -> libprotobuf10

Other things that the mod_pagespeed team thinks of as dependencies,
but are probably properly considered part of mod_pagespeed.  Currently
nothing outside of mod_pagespeed depends on them:

    base64
       from http://www.adp-gmbh.ch/cpp/common/base64.html
       very small dependency
       local modifications to add a web-safe encoding

    chromium
       mod-pagespeed fork of a selection of the chromium base libraries

    css_parser
       google-developed css parser library that's only released via
mod-pagespeed

    domain_registry_provider
       public suffix list library

    mod_spdy
       APR_DECLARE_OPTIONAL_FN declarations for mod_spdy integration

    rdstl
       the hash map from redSTL and other portions of redSTL that it depends on
       it benchmarked ~2x faster than stl::hash_map

The messiest problem is probably what to do with serf, the
url-fetching library.  Debian does have libserf-1-1, but mod_pagespeed
has made a lot of local modifications:
https://github.com/pagespeed/mod_pagespeed/blob/master/third_party/serf/serf.diff

These patches fall into three categories:
* not needed when packaging with debian:
   * adding APR < 1.3 support
   * type casting for pedantic compilers
   * disabling authentication support
   * boringssl compatibility
* bugfixes that are good but not critical
   * if a response has both Content-Length and Transfer-Encoding then
     T-E should take precedence by spec, but serf goes with C-E.
   * extra NULL checks
* things mod_pagespeed needs
   * a way to receive unmodified (still gzip-encoded) responses
   * a way to ask if a connection is in an error state
   * a way to separately set the host header and the site to connect to
   * a way to specify the ssl cert directory
     * thin wrapper around SSL_CTX_get_cert_store/X509_STORE_load_locations
   * a way to check that a cert is valid for a particular host
     * thin wrapper around X509_check_host

There's also the nginx port, ngx_pagespeed, and while that doesn't add
any dependencies on its own beyond the ones in mod_pagespeed it
expects to load most of mod_pagespeed statically, as psol.a, and it
would need to be modified to be able to load things dynamically.

Jeff Kaufman
mod_pagespeed team