/etc/default/X and upstart jobs

[Clint Byrum]

I've run into a number of bugs where on upgrade from an older release,
the /etc/default files are no longer respected:

https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/557054
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/570103
https://bugs.launchpad.net/ubuntu/+source/cron/+bug/486558

Essentially while porting things to upstart, the /etc/default files are
being forgotten. Not all packages have forgotten them, but some have.

Further, the format and location of these files is an anachronism from
before we had upstart. Noted succinctly by Colin Watson here:

https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/531912/comments/6

We really shouldn't need these separate files because upstart jobs
should be extremely simple. So this is only a partial fix:

[ -f /etc/default/squid ] && . /etc/default/squid

This also has a small effect on the system boot speed by forcing a
random seek into /etc/default to read this tiny file. One of the ideas
behind upstart was to alleviate these things by pulling all of this
information into one place (the job config) which is read entirely in
one sweep early in the boot.

So I'd like to propose that we convert these values into env lines in
upstart scripts upon installation. What I mean is that we should have a
policy where upstart jobs define any pre-existing variables
from /etc/deafult/foo with the same defaults:

So, for instance, in the openssh-server package, we have this
in /etc/default/ssh:

# Options to pass to sshd
SSHD_OPTS=

This should become

# Options to pass to sshd
env SSHD_OPTS=

(and the env var added to the exec line)

Then the dh_installinit program should add code like this to the
maintainer script for upgrades:

service=ssh
jobfile=/etc/init/$service.conf
defaults=/etc/default/$service

if [ -f "$defaults" -a -f "$jobfile" ] ; then
  for i in `awk -F"^env " '/^env / {print $2}' $jobfile` ; do 
    name=`echo $i | cut -d= -f1`
    val=`echo $i | cut -d= -f2-`
    setvalue=`sh -c ". $defaults ; echo \\$\$name"` 
    if [ "$setvalue" != "val" ] ; then 
      finalvalue=`echo $setvalue | sed -e 's/,/\,/g'`
      sed -ie \
        "s,^env $name=.*,#converted automatically from $default\, content saved in /var/backups/$service.default-deprecated\nenv $name=$finalvalue," \
        $jobfile   
    fi
    mv $defaults /var/backups/$service.default-deprecated
  done
fi

Right now we are breaking on upgrade because people may not remember
that they modified /etc/default, and we're not stopping to tell them at
any point that we're going to ignore the file. Even if we keep sourcing
the file, this is less than ideal as one of the goals of moving a
service to upstart should be to simplify its start configuration.

This shouldn't count as a policy violation where a maintainer script is
editing a conffile, because we're simply folding modifications
to /etc/default/foo into /etc/init/foo.conf. They were going to get a
conffile warning about /etc/default/foo .. so now they're going to get
it about /etc/init/foo.conf, and it will include automatic configuration
warnings so they know how it happened.

Another less aggressive option would be to just warn the user that the
values in /etc/default/foo need to be manually ported forward.

I don't know if this warrants a full UDS discussion, but if it is a
viable option, I would like to see this started very early in the
oneiric cycle, and completed by a2 or at the very least a3.

So, does anybody

a) think we need a UDS session to discuss this

and/or

b) want to +1 on this so I can start filing wishlist bugs targetted at
oneiric?

Also this brings up another question.. where do we actually state our
policy differences from Debian policy?