= 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.

-- 
main inclusion request: update-motd
https://bugs.launchpad.net/bugs/260443
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to