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

 * 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)
