Charles Plessy, 2014-08-27 06:56+0900:
I am unsure what the standard practice is in this situation. Can you and others comment on the existence or not of alternatives, in Debian and elsewhere ?
The only alternatives I know of are: 1. to put all the configuration in the cron job script itself; 2. to put that configuration somewhere else in /etc.
If we document the use of /etc/default to configure cron jobs without considering alternatives, the risk will be to push towards a Debian-only standard, or worse, to push maintainers to modify upstream cron jobs using a legitimate way to configure, but not using /etc/default.
Well, I think there are mostly two kind of packages that use cron jobs. First, software which use is partly based on a cron task, like logrotate, sks, apticron, popularity-contest, etc. For these packages, the cron job is normally provided in the upstream source, and for what I have seen, if needed they usually refer to a configuration file located in /etc but not /etc/default, like /etc/sks/cron.conf.
And second, software for which a cleanup or update task, while not essential to their use, is useful and has been added by the Debian package maintainer, like apache2 or bsdmainutils for instance, a configuration file /etc/default/package is used.
My opinion would be to keep packages of the first type as they are, as the cron job is part of the upstream source and should not be modified (unless it does thinks like violating the FHS, that is). In fact, my proposal was rather to issue a recommendation for Debian packagers when they have to instal a cron job and allow the user to alter its behaviour with a configuration file.
-- ,--. : /` ) ن Tanguy Ortolo <xmpp:tanguy@ortolo.eu> | `-' Debian Developer <irc://irc.oftc.net/Tanguy> \_
Attachment:
signature.asc
Description: Digital signature