On 09-Jan-1998 13:03:45, Martin Schulze <[EMAIL PROTECTED]> wrote: > 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.
Difference, not incompatability -- Debian cron will continue to run quite happily without the presence of /etc/cron.d. And since Paul hasn't issued a patch to cron for several *years*, I agree that it is unlikely that he'll add this patch. There are already several "#ifdef DEBIAN" places in the code. > . /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. Many unix systems I've had a /etc/crontab (quite a few, and quite a variety), which is quite distinct and serves a totally different purpose than root's crontab. > . 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. cron *doesn't* need it. This all came up because of a claim that many programs *do* need it. If that claim is incorrect, then we > . /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. It already does this for /etc/crontab and all the user crontabs. Adding another directory is *not* a big deal; trust me, I looked at the code before agreeing. It is, for example, much easier that writing a *correct* update-crontab script. > 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. The problem with this is that once the package-provided program has modified the file, the file is (quite properly) considered "changed" by dpkg, which will then whine about the next time distributed version changes (and thereafter, I think). There are *so* many issues in writing an update-crontab (think about upgrades from the existing system; user changes to individual lines vs. package changes, etc.). Letting each package have it's own conffile in /etc/cron.d solves most of those. I agree that the difference is somewhat awkward, but I think it's better (simpler, more reliable) than the alternatives. steve -- Steve Greenland -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
