Re: Proposal to improve package configuration upgrades
Harald Braumann <harry@unheit.net> writes:
> I don't really know Config::Model. But the main problem I have with the
> current system is, that I only see diffs between the currently
> installed version and the new package version.
With ucf, you see a diff between current file (i.e. installed version
with your modifications) and the new package version.
> No what I really would like to see is the diff between the last version
> I've merged and the new package version.
I fail to see the differences (no pun intented) between "the last
version I've merged" and the current file ...
> So changes can easily be seen (changes in defaults, new/removed
> parameters or just white-space changes?) and merging would work
> without a conflict in most cases.
With Config::Model:
- you would not see white space or any other formatting difference
- your customized values would be merged into the new package file
(more accurately, loaded in Config::Model configuration tree using
the new package *model*). Thus you would see the delta between your
new file and the new default value. See this example of a screenshot
[1] where the config values different from "default" are shown with
a green arrow
- yes, merging would work mostly without conflict
> Similar to like SCMs work.
The main difference between a SCM and Config::Model is that a SCM
works purely at text level without knowledge of the semantic of the
file under control. OTOH, Config::Model uses the semantic knowledge
provided by the model to perform the upgrade.
> Config::Model could be useful in addition, but would it support such a
> work-flow?
Provided I've understood correctly your work-flow, I'd say mostly yes...
All the best
[1] http://freshmeat.net/screenshots/69123/74589/
--
Dominique Dumont
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner
irc:
domidumont at irc.freenode.net
ddumont at irc.debian.org
Reply to: