Upstream's complete overhaul of the configuration file - And future handling

[Gunnar Wolf <gwolf@gwolf.org>]

Hi,

The new upstream version of a package I maintain (Cherokee, a
lightweight extensible web server) requires the configuration file to
be completely rewritten - Version 0.6.x will just not parse 0.5.x's
config file. It does ship a converter, but of course, nobody will
claim it is perfect. 

The new configuration file is not meant to be hand-edited (although it
can, it is not a binary registry)

So, I'm planning the following flow - Please correct me if you feel
I'm missing something:

1- At preinst, ask via Debconf if user wants the script to perform the
   automatic conversion. 
2a- If user does not want automatic conversion, just display what would
    have been done, and signal the daemon not to start (i.e. setting a
    variable in /etc/default/cherokee). Should I leave the old
    Cherokee instance running, or should I leave it in a stopped
    state? 
2b- If the user does want automatic conversion, do it - and leave the
    daemon running. Leave old configuration as reference, appending
   .old to filename.

Does this sound sensible?

Now, regarding the future handling (and that's why I'm Cc:ing Álvaro,
the Cherokee author): The configuration is handled by cherokee-admin,
a separate Cherokee server with a built-in and limited
configuration. I don't think cherokee-admin is expected to be active
at all times, but then again, it feels a bit awkward just to issue a
command-line argument to start a server whenever I want to tweak my
configuration. Do you think cherokee-admin should be started at boot
time? (of course, this would be done using a separate initscript)

Thanks for your comments.

-- 
Gunnar Wolf - gwolf@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF