Steve Greenland writes ("Re: Bug#4204: cron does not install if /usr/sbin/cron
does not exist!?"):
> Yves Arrouye wrote:
...
> > marin13# dpkg -i cron_3.0pl1-33.deb
> > (Reading database ... 22220 files and directories currently installed.)
> >
> > Preparing to replace cron (using cron_3.0pl1-33.deb) ...
> > start-stop-daemon: unable to stat executable `/usr/sbin/cron': No such file
> > or d
> > irectory
> > dpkg: warning - old pre-removal script returned error exit status 2
...
>
> Interesting. It's failing because it's an upgrade (otherwise prerm
> wouldn't be called), but /usr/sbin/cron isn't there. I'm able to
> duplicate it by simply rm'ing cron, and then trying to do pretty
> much anything with dpkg -- install doesn't work, and neither does
> remove. I've tried --force-reinstreq ('cause one of the messages
> >from dpkg is "Package is in a very bad inconsistent state - you
> should reinstall it before attempting a removal.") but that doesn't
> help. I'm not sure how to get out of this other than going down
> into the bowels of /var/dpkg and messing with the prerm script:
> I don't see a --ignore-script-errors option for dpkg.
I could add one, of course, but it's probably a bad idea.
...
> They're supposed to have -e set. I'm not inclined to modify the
> script to check for /usr/sbin/cron, because the if the prerm script
> is called, then the cron package is installed, and the cron program
> is supposed to be there. If it isn't, then the file has been removed
> by manipulations outside the domain of the dpkg/dselect.
Indeed.
> If all the package scripts are supposed to deal with things happening
> outside the control of dpkg/dselect then I have about 300 bug
> reports to file :-).
Quite.
> I'm not closing this bug yet, because I would like to know if there
> is a way around this problem (other than 'touch /usr/bin/cron', which
> may well be the best answer).
I think that `touch /usr/bin/cron' is the best answer.
Ian.
