Hello,
For a complete discusssion see http://bugs.debian.org/183357
Currently the exim4-packages cannot provide /usr/sbin/exim (only
/usr/sbin/exim4) because exim v3's init script up to version 3.36-4
uses something aequivalent to this to check whether it should do
anything: [ -x /usr/sbin/exim ] || exit. If you had exim v3
uninstalled (but not purged) and installed exim v4 and it contained
/usr/sbin/exim both init-scripts would try to run a daemon. THe ame
applies to the cron-snippets.
The exim3 init script in sid has already been changed to use another
test that recognizes exim v3 properly but this doesn't help the users
who will upgrade from woody to sarge (when it is stable), switching
directly to exim v4 without installing eximv3 from sarge first. This
leaves me with these possibilties:
* don't ship /usr/sbin/exim in sarge, wait for sarge+1. I'd rather not
do that because it'll take imho at least another two and a half
years.
* do something unclean. See below.
Idea:
* postinst configure
1 When eximv4 is installed check whether eximv3 conffiles using the
bad test are installed, otherwise goto end
2 move the respective file to $file.exim4disabled and generate a new
$file that says "This file has been temporarily renamed, see
$file.exim4disabled."
* postrm uninstall:
if [ -e $file.exim4disabled ] && md5sum shows it is not changed
if [ -e $file ]
# exim v3 has still not been purged
mv $file.exim4disabled $file
else # exim v3 has been purged
rm $file.exim4disabled
fi
else do nothing.
Is this allowed? Yes[ ] No[ ]
Is this too fragile Yes[ ] No[ ]
Better ideas?
I won't add a debconf question "May I temporarily move...." because
imho _either_ my proposal is good enough anyway and there is no use
asking *another* useless question _or_ if it not allowed I would have
to use priority high and default to no.
thanks for reading, cu andreas
