Re: Proposal to improve package configuration upgrades
Harald Braumann <email@example.com> writes:
>> I fail to see the differences (no pun intented) between "the last
>> version I've merged" and the current file ...
> I mean the last maintainer version I merged into the installed version,
> not the result of the last merge.
> But there are 3 possible situations here:
> 1. value has been changed between the last and the new maintainer
> 2. value was modified locally
> 3. both of the above
> In case 1 the modification could be merged silently, in case 2 the
> modification should be left alone and in case 3 I'd have to decide what
> to do. Config::Model on its own couldn't tell the difference.
Currently a maintainer set some value in a package config file to
reflect his decisions or debian policy or whatever.
With Config::Model such decision would not be encoded in the delivered
config file but in the model of the configuration file. This would be
specified in the configuration model as a default value.
Here's what will happen during an upgrade:
a. Config::Model will dump customized value somewhere (dump values
which are different from maintainer's model version N. i.e. this
will keep track of values from case 2 and 3 *if* they are different
from the default value specified in the old model version N ).
b. application model is upgraded from N to N+1 (case: 1 and 3: some
default config values are changed)
c. Config::Model performs the merge:
* case 1: no customized value stored in step a. Config::Model will
write the default value (specified in the new model version N+1)
in the config file
* case 2: customized value stored in step a. is loaded, checked and
will be written in configuration file
* case 3: just like case 2
I hope this replies to your concerns. If not feel free to ask more
>> - 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.
> You could apply the way merges work in an SCM to structured
More often than not, the order of the configuration data is not
important. For SCM merge, this order *is* important.
> Having the diff between the last and the new maintainer version is not
> an alternative to Config::Model. The former can tell me what has
> changed in what way and the latter can present this information
> enriched with its semantic knowledge of the changes. Both are things I
> find useful. So my question is, if Config::Model can also deal with the
> additional information of what has changed how, so the two things could
> be combined?
Config::Model can only show the diff between the current state
(current file or file + modifications) and the default values from the
configuration model. There's no notion of history or diff with
previous version of a configuration file. Well, not yet. I'll have to
think about this...
All the best
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner
domidumont at irc.freenode.net
ddumont at irc.debian.org