Bug#257726: debian-policy: Please remove virtual package cron-daemon
On Mon, Jul 05, 2004 at 10:54:14AM -0500, Steve Greenland wrote:
> The problem is that merely defining a 'cron-daemon' virtual package is
> pointless. One must also define what interfaces it supports.
One could make that same argument about many of our virtual packages.
Do you want to try to define the exact boundaries of what is and isn't
a proper "emacsen"? Policy may define the behavior of mail-transport-
agent, but does it define mail-reader? Or x-audio-mixer? Or
c-compiler? Or wish? (As the Tcl/Tk maintainer, I can assure you
that the definition of "wish" is quite a moving target.)
Doesn't POSIX have something to say about cron? I find references to
POSIX 1003.1 and POSIX 2 out there.
> What does package providing 'cron-daemon' promise:
It promises that your package provides a cron daemon. What's so hard
about that? If you want more, well, we've got an international
standard, and we've got the needs of the project to provide a high
quality, working system. If someone makes a cron-daemon that doesn't
meet our needs, I think it'll be pretty obvious. And breaking things
is always a bug no matter what policy says. Policy just makes it
easier to assign blame when it's unclear who's at fault. But then so
do international standards.
Anyway, I'm not saying I disagree with you (this is not a formal
objection), but I'm not sure I agree with you either. If you really
think we should nail down the definition of a cron-daemon a little
more specifically, I'd rather see us do that than move backwards.
We managed to cope with the differences between /bin/sh and /bin/bash
fairly well, even though a lot of developers outside of the project
seem unaware that there is such a distinction. I can type "sed
'1c#!/bin/bash'" in my sleep at this point. So, maybe we'll have to
do a little cleanup of how our packages use cron, and what assumptions
they make about cron -- isn't that potentially a good thing?
> 1. Correct execution of /etc/cron.{hourly,daily,weekly,monthly}?
Insofar as the contents are reasonably standards-compliant, any
reasonably standards-compliant cron should be able to handle this,
yes. But aside from the problem of "vixieisms" (analogous to
bashisms), which I think we should fix, I think that not supporting
this would pretty clearly break things, which would be a bug no matter
what policy does or doesn't say.
> 2. Correct execution of /etc/cron.d?
See above.
> 3. /usr/bin/crontab?
POSIX says yes.
> 4. /var/spool/cron/crontabs/* (think 'upgrade' from vixie cron to a
> different 'cron-daemon' provider)
I don't know, do any of our packages use this? And if not, why do we
care? And even if they do, is it something we could fix if we needed
to? Is it POSIX? I don't know. Does it matter? Not as far as I
can tell. If it matter, well, then doesn't that answer your question
right there?
> 5. What subset of the syntax/semantics described in crontab(5) are
> supported (affects 2, 3, and 4.)?
A sufficient amount of whatever POSIX defines to avoid breaking too
many of our packages?
> Until these questions are answered and published in debian-policy, the
> cron-daemon virtual package should not be allowed.
I disagree. If anything, I'd say that there are too many standards
for cron, not too few. But I don't disagree enough to object if you
can get a concensus. I'm perfectly happy with my current cron. :)
--
Chris Waters | Pneumonoultra- osis is too long
xtifr@debian.org | microscopicsilico- to fit into a single
or xtifr@speakeasy.net | volcaniconi- standalone haiku
Reply to: