Package: debian-policy
Version: 3.5.8.0
Severity: minor
I don't think you are going to fix it at this late date, but next time
please try to follow Unix traditions about $? and emitting error
messages upon failure.
10.3.2. Writing the scripts
---------------------------
These scripts should not fail obscurely when the configuration files
remain but the package has been removed, as configuration files remain
OK, 1."fail" 2."obscurely"
Well, the problem was #2 but the design decision was to instead change
the reporting of #1. So now indeed the obscureness was not fixed, but
failures are no longer detectable.
What if the same design was carried over to rm(1) cp(1) mv(1). I
intend to do an operation but can't tell by $? if it succeeded and
can't count on stderr for failure notices.
on the system after the package has been removed. Only when `dpkg' is
executed with the `--purge' option will configuration files be
removed. In particular, as the `/etc/init.d/<package>' script itself
is usually a `conffile', it will remain on the system if the package
is removed but not purged. Therefore, you should include a `test'
statement at the top of the script, like this:
test -f <program-executed-later-in-script> || exit 0
On system A:
/etc/init.d/bla_bla start; echo $?
starts bla_bla.
On system B:
/etc/init.d/bla_bla start; echo $?
doesn't start bla_bla. $? is the same.
Apparently error message "no news is good news" doesn't apply here either.
Yes, this is all intentional and any changes now will probably break
lots of stuff, but would K&R have done it this way?
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux debian 2.4.20-k7 #1 Tue Jan 14 00:29:06 EST 2003 i686
Locale: LANG=zh_TW.Big5, LC_CTYPE=zh_TW.Big5
-- no debconf information
