handling cronjob not defined at install

[Jereme Corrado <jereme@zoion.net>]

Hello List,

      I maintain faqomatic and I recently made some changes to the
      package and the source itself to address a bug, (271776).  It's
      more than I have changed before so I just wanted to run it by
      the list to make sure it's all sensible.

      The bug points out that FOM installs a cronjob into www-data's
      crontab.  This job performs some hourly maintenance on your FOM,
      checking for bad links, etc.  The bug reporter requested that
      the job be moved to /etc/cron.hourly as they felt it was a more
      natural place to look.  I thought about it and read through
      policy and seams to me they are right, (with the small
      difference that it seams an hourly job should go in
      /etc/cron.d/faqomatic).

      The only twist is that the cronjob cannot be written at the time
      of package install, it has to be created when the local admin
      configures their FOM.  My first thought was to hack the FOM
      source so it installed the cronjob in the new spot.  To
      fascilitate this I had the package install an empty cronjob file
      in /etc/cron.d owend by www-data with usable perms.  When the
      istaller gets to the cron configuration step it just writes to
      that file.

      But as I thought about it, I didn't really like this solution.
      I marked /etc/cron.d/faqomatic as a conf file so it wouldn't get
      overwritten on upgrades but since the file is empty at the time
      of install, dpkg checks with you when you re-isntall or upgrade.
      So I started thinking the empty intial file approach was sort of
      flawed.  So I chopped on the FOM source once more and had the
      installer write out a conf file in the director where FOM stores
      other such business, (/var/lib/fom/meta).  Then I just set up
      /etc/cron.d/faqomatic to use this, so now the cron job doesn't
      change unless you edit it.  I like this better but it meant
      changing FOM a bit.  The only other detail is that the original
      cronjob loaded a FOM module and invoked a sub, rather than
      calling some script.  I took this as my lead and added a Debian
      specific module to the FOM tree, (FAQ::OMatic::Debian), the
      cronjob loads this and calls a sub, this so it sort of maintains
      the spirit of the original approach.

      Was this a reasonable way to handle this?  Should I just have
      went with the empty cronjob approach?  Sorry that was so long.



thanks,
jereme