Comment 8 for bug 260443

= Cron job =

I really think we need to lose the debconf configuration of cron job frequency. I know that you've put effort into making it at least somewhat policy-compliant, but:

 * no other package that I know of offers debconf configuration of cron job frequency, so system administrators will not expect it;
 * CAPITALISED HEADERS telling people not to edit files in /etc/ are ugly, and have never been popular;
 * extra debconf-based configuration file management is always complicated and is typically a source of bugs;
 * I don't see where you've justified the need for this.

Honestly, a file in /etc/cron.d/ is trivial to edit, and editing files is the perfectly normal interface to changing cron job frequencies. I don't think it's at all necessary to add debconf configuration on top of this, and I think it is probably going to do more harm than good (on You Ain't Gonna Need It principles: bugs are correlated with number of lines of code, so unnecessary features should be removed).

I know the temptation to add debconf configurability for everything: I used to do it a lot. I later realised that it was causing me more problems than it was solving, so had to spend time ripping it out again.

In this case, most system administrators will find it entirely unsurprising that they should edit a file in /etc/cron.d/ to change the frequency of a cron job; very few of them will think to run dpkg-reconfigure to do so, even those familiar with Debian-based systems, because Debian has never had a standard practice of using debconf to configure cron job frequencies.

= Start/stop =

I think I'm OK with the start/stop semantics now. They are confusing at first glance, but essentially it's starting up a "daemon" whose existence is time-multiplexed. :-) Specifically, they are no longer modifying system state that will persist across reboots, which would definitely be intolerably confusing as no other init script works that way.

= Miscellaneous =

Don't use db_stop unless you know exactly what it does and you're sure you need it; it has surprising semantics (in particular, it doesn't put your file descriptors back the way they were to start with ...) and can cause problems. In the case of a daemon, it's usually better to make sure that the daemon closes file descriptors on startup. In this case, you aren't starting a daemon so there's no need for it.