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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
