exim4 install fails with error: incompatible command-line options

BTW, I followed-up on the "hostname: Unknown host" message above. I've set the hostname properly, purged and re-installed exim4-daemon-light, with the same "incompatible command-line options" error message.

This appears to be the Debian bug which has been fixed:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477194

A work-around which solved it here is to edit "/etc/init.d/exim4" and remove the quotes surrounding variables holding optional parameters passed to start-stop-daemon, since if those variables are empty a pair of quote-marks will be passed to start-stop-daemon.

After editing the file force apt to fix-up the packages:

sudo apt-get -f install

=== /etc/init.d/exim4 fixed start_exim() function ===

start_exim()
{
  [ -e /var/run/exim4 ] || \
    install -d -oDebian-exim -gDebian-exim -m750 /var/run/exim4
  case ${QUEUERUNNER} in
    combined)
      start_daemon -p "$PIDFILE" \
        "$DAEMON" -bd "-q${QFLAGS}${QUEUEINTERVAL}" \
        ${COMMONOPTIONS} ${QUEUERUNNEROPTIONS} ${SMTPLISTENEROPTIONS}
      log_progress_msg "exim4"
      ;;
    separate)
      start_daemon -p "$PIDFILE" \
        "$DAEMON" -bd ${SMTPLISTENEROPTIONS} ${COMMONOPTIONS}
      log_progress_msg "exim4_listener"
      start_daemon -p "$QRPIDFILE" \
        "$DAEMON" -oP "$QRPIDFILE" \
        "-q${QFLAGS}${QUEUEINTERVAL}" ${QUEUERUNNEROPTIONS} ${COMMONOPTIONS}
      log_progress_msg "exim4_queuerunner"
      ;;
    queueonly)
      start_daemon -p "$QRPIDFILE" \
        "$DAEMON" -oP "$QRPIDFILE" \
        "-q${QFLAGS}${QUEUEINTERVAL}" ${QUEUERUNNEROPTIONS} ${COMMONOPTIONS}
      log_progress_msg "exim4_queuerunner"
      ;;
    no|ppp)
      start_daemon -p "$PIDFILE" \
        "$DAEMON" -bd ${SMTPLISTENEROPTIONS}
      log_progress_msg "exim4_listener"
      ;;
    nodaemon)
      ;;
  esac
}

Agreed, the workaround resolves the problem and the bug documented in the Debian report appears to be the cause.

Hardy's going to be with us for a long time. Can we get this workaround/a patch in the next incremental release?

This was fixed in Debian version 4.69-3 in April 2008, included in Intrepid (4.69-5) but too late for Hardy (4.69.2). Failure to install is a pretty serious failure.
This bug requires an SRU or backport to fix.
Nominating for SRU

Fixed in intrepid and above.

Confirmed that this sounds like a worthwhile SRU. Assigned to server team, but if you feel like digging out/testing the patch or even prepare a debdiff for sponsoring, that would be much appreciated, of course.

The patch looks sane, however I fail to reproduce the issue.
Installing exim4-daemon-light on up-to-date hardy just works for me.

Looking at the Debian bug we are experiencing something different. Their issue was triggered by a change in how start_daemon handles args in lsb>=3.2-9, and hardy runs with 3.2-4ubuntu1. Running the init script in debug mode, in particular, shows no empty ('' '' '') arguments in the start-stop-daemon call :

$ sudo EX4DEBUG=1 /etc/init.d/exim4 start
...
+ /sbin/start-stop-daemon --start --nicelevel 0 --quiet --exec /usr/sbin/exim4 --oknodo --pidfile /var/run/exim4/exim.pid -- -bd -q30m
...

Could someone that experienced that issue confirm lsb-base version and send the result of the "sudo EX4DEBUG=1 /etc/init.d/exim4 start" command ?

Anyone reproducing the issue could answer to my last questions ?

Hardy has seen the end of its life and is no longer receiving any updates. Marking the Hardy task for this ticket as "Won't Fix".