On Thu, Jan 08, 1998 at 11:07:52PM -0600, Steve Greenland wrote:
> This seems to be the consensus, and it's my favorite too, and looks to
> be easy to implement (especially given the nice way that cron reads/parses
> crontabs).
>
> Here's the proposal:
>
> In addition to reading /etc/crontab, the cron daemon will also
> read each file in /etc/cron.d (chosen for similarity to init.d). Each
> of the files in cron.d is considered a crontab "fragment", and should
> be formatted exactly as /etc/crontab (i.e. with the username specified).
> The end result will be just as if cron read the result of
>
> cat /etc/crontab /etc/cron.d/*
>
> Packages requiring faster than daily intervals, or irregular
> intervals, should place the appropriate crontab fragment in
> /etc/cron.d/packagename. This file should be marked as conf file, so
> that the sysadmin may change it. The files in /etc/cron.d will be
> checked for changes (via stat()) every minute, just as /etc/crontab is;
> therefore there is no need for action in the postinst.
I object to this proposal. I'd rather have only _one_ systemwide crontab
called /etc/crontab than introducing a new directory for these reasons:
. /etc/cron.d is fully incompatible to any other flavour of Linux
or Unix. As far as I know Paul Vixie I don't think that he's
going to include this patch to the cron package. So it would
be a special Debian incompatibility.
. /etc/cron.d would make the system more difficult to maintain
because they have to check yet another directory where crontabs
get stored. At the moment many people are already confused that
there is /etc/crontab and not only /var/spool/cron/crontabs/root.
. I don't see the need for introducing another directory just
for three packages that might need it (ipac, cron, <forgot the name>).
If there was heavy use of /etc/crontab, perhaps in conjunction with
problems breaking crontab &c, but there aren't. In the past there
were problems with at/atrun, but that's superceeded by atd as
standalone program.
. /etc/cron.d would make cron itself much more complicated. It
has to watch the directory to change, it has to watch each file
in it to change, more timestamps need to be remembered.
. Our policy contains a clear statement on what to do:
3.3.7. Configuration files
--------------------------
[..]
If two or more packages use the same configuration file, one of these
packages has to be defined as *owner* of the configuration file, i.e.
it has to list the file as `conffile' and has to provide a program
that modifies the configuration file.
The other packages have to depend on the *owner* package and use that
program to update the configuration file.
Sorry that I only speak up now, but I was too busy before (and I still am)
Regards
Joey
--
/ Martin Schulze * joey@infodrom.north.de * 26129 Oldenburg /
/ Whenever you meet yourself you're in a time loop /
/ http://home.pages.de/~joey/ or in front of a mirror /
Attachment:
pgptcxX3CmNMF.pgp
Description: PGP signature