Re: Fwd: Upstream's complete overhaul of the configuration file - And future handling
Sorry for being a day late, but I didn't give it much thought until now.
The flow suggested by Gunnar seems sensible enough, but starting cherokee-admin at boot time makes no sense to me.
May be the easiest thing would be not launching cherokee-admin at all and having the default placeholder webpage mention the way to launch the configuration program.
If not, and if cherokee-admin must be launched via Debocnf, how about halting the setup process until the web interface has been properly used?
Afterwards Debconf would resume after being signaled by the user and it could simply stop cherokee-admin and proceed as usual.
I believe the simplest thing would be not calling the configuration interface and simply pointing out its existence at the wellcoming page.
Of course this would only apply if the conversion between config files wasn't done or it was a new installation.
On 25 Mar 2008, Alvaro Lopez Ortega wrote:
> Begin forwarded message:
> > From: Gunnar Wolf <email@example.com>
> > Date: 25 March 2008 16:46:48 GMT+01:00
> > To: firstname.lastname@example.org
> > Cc: Álvaro López Ortega <email@example.com>
> > Subject: Upstream's complete overhaul of the configuration file -
> > And future handling
> > 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 - firstname.lastname@example.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
> Greetings, alo.