[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposal to improve approx configuration upgrades

Hello Eric

Le mercredi 7 octobre 2009 13:09:06, vous avez écrit :
> I don't really want to add a dependency on another package for such a
> simple task.

Simple, but it may be repetitive. Here a real life comment made by one of your 
users on #debian-perl:

(03:02:23 PM) dusty: ddumont1: thanks for writing that doc.  I didn't even 		
know that existed.  I may see about using it in my own packages.  Your approx 
example really hits me because we use approx all over the place and have been 
hit with the recent (in the etch to lenny transition) changes to the config 
format of that file.  It was always great fun to update our approx settings... 

This kind of migration could be handled by config::model: the old syntax would 
be replaced by the new one. My patch would ensure that this upgrade is done at 
package upgrade time (although I arrived too late for Etch to Lenny migration 
:-p )

> Anyone deploying a caching proxy server should be able
> to read a man page and edit a config file.

That's a fair point. Approx users are not average users.
> In general, if you want your approach to be adopted, I suggest making
> it more separate from the packages themselves and more incremental.

Yes, but the idea is to handle config upgrade during package upgrade. I do not 
know how this can be done outside of the upgraded package.

> Perhaps you could follow the model of logcheck, or ifupdown --
> standardize on a directory that each package can put their scripts in,
> so it works if your config tool is installed, but has no effect
> otherwise.

I'll have to think about it. I do not know how to trigger the execution of 
'config-edit' this way.

> Also, I haven't looked into either one in enough detail, but how does
> your approach differ from ucf?

ucf has a rather crude upgrade strategy: either accept upstream or keep your 
file or use your favorite editor. That's not very cool for average users. 

config-model is more subtle: upstream/packager data are merged with user data  
without user interaction. As a bonus, the user will get a GUI with integrated 
help to edit the configuration (I acknowledge that this may not be seen as a 
bonus for hardboiled sys admins ;-) )

All the best

Reply to: