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.