Debian packaging work needed for sks
------------------------------------

 * rethink /var/lib/sks/www/* -- people like to customize these files.
   is this the best place to ship these, or to serve from?  They get
   overwritten upon upgrade, which might mean we're encouraging admins
   to lose some of their work.  configfiles?  symlinks?  something else?

 * try to get as many of our patches upstream as possible

 * rethink our debian FHS support patches -- can this be done in a
   less-invasive fashion?  Why hard-code things?  It should be
   possible to run multiple sks instances on a single host.

 * trim the default sks configs so there is less for an admin to read
   through.

 * improve the documentation of sks for configuration purposes;
   DB_CONFIG? relationship between sks commandline args and config
   file?  (this might be upstream work)

 * move sks to /usr/bin ; there is precedent for daemons in /usr/bin,
   the daemon doesn't run as the superuser, and it's possible for
   normal users to run sks.

 * update sks to allow socket activation:
    - sks db needs to be socket-activated by:
      * the db_com_sock
      * the hkp_port(s) -- could be more than one
    - sks recon needs to be socket activated by:
      * the recon_com_sock
      * the recon_port(s) -- could be more than one

 * find someone who might want to maintain the sysv initscripts --
   maybe move them to a separate binary package for those who want to
   use sysvinit?

 * make a standard public-facing setup easy to produce (reverse proxy,
   hkps, tor, automated setup, etc)

 * improve database management and backup management -- automated
   reasoning about available space, reporting about processing time,
   etc.

 * reconsider regular stat generation -- systemd timers?  cronjobs? or
   just encourage reliance on sks itself to update stats regularly?

 * detect sks hanging or database deadlock?  figure out how to recover
   from it (or even better: prevent it)

 * reconsider how to ship ocaml bytecode -- maybe this is an
   sks-arch-indep or sks-bytecode arch:all package (which Provides:
   and Replaces: sks) instead?  and we just wouldn't build the
   binaries on systems without ocamlopt.

 * upstream ships with "KDB", but we've historically shipped with "DB"
   for the key database.  can we transition to match upstream?

 * explicitly deprecate use_port_80 (encourage the use of socket
   activation instead)
