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:
<quote>
(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...
whee.
</quote>
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
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
