Bug#257726: debian-policy: Please remove virtual package cron-daemon
On 05-Jul-04, 14:11 (CDT), Chris Waters <xtifr@debian.org> wrote:
> 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.
Yes, and I think we should.
> Do you want to try to define the exact boundaries of what is and isn't
> a proper "emacsen"?
This is defined by example, I think: GNU Emacs or Xemacs.
> 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.)
I'd say 'c-compiler' is pretty easy; ISO C89. Although I'm not sure what
use a dependency on 'c-compiler' is.
The rest are, in fact, useless, because they provide no useful
information, at least not at the package dependency level.
> 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?
I'm specifically interested in what I, a packager, can expect
a "Depends: cron-daemon" to provide. Can I stick a script in
/etc/cron.weekly and reasonably expect it to be executed once a
week? Can I stick a crontab fragment in /etc/cron.d, and expect it
to be treated appropriately? Can I run '/usr/bin/crontab -u foo
/usr/share/foo/bar' in my postinst? What?
> 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.
The files in the aformentioned directories are scripts, not crontabs,
and are run by run-parts. A script of the form
# !/bin/sh
while /bin/true; do
run-parts /etc/cron.daily/
sleep 86440
done
might meet this requirement.
> > 2. Correct execution of /etc/cron.d?
>
> See above.
Different, and harder.
> > 3. /usr/bin/crontab?
>
> POSIX says yes.
Okay.
> > 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?
If you change from vixie-cron, which uses this directory to store user
crontabs, to another implementation, is it required to use or convert
those existing crontabs?
> 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?
It matters for upgrades.
>
> > 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?
Fine with me. Maybe I can remove all the @hourly type crap :-).
My point is that there is NOTHING about "Depends: cron-daemon" that
provides any useful gaurantee to a package as it now stands. That the
same statement is true for many other virtual packages doesn't mean
that we should keep 'cron-daemon', it means we should junk the others
unless/until someone can provide something better.
The most useful functionality provided to packages is
"/etc/cron.{d,daily,weekly,monthly}", and I'm pretty sure that's not in
any POSIX standard...
Steve
--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net
Reply to: