Re: Proposal to improve package configuration upgrades

[Dominique Dumont <dominique.dumont@hp.com>]

Harald Braumann <harry@unheit.net> 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. 

ok

> But there are 3 possible situations here:
> 1. value has been changed between the last and the new maintainer
> version
> 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
questions.

>> - 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
> information.

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

-- 
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