Upstream's complete overhaul of the configuration file - And future handling
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
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
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 - email@example.com - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF