Re: RFC Debian package upgrade with Config::Model
Hello Jonas
Sorry for the delay in replying. I'm getting late in preparing my
presentations for French Perl Workshop, so I have less available time to
work on package upgrades.
Jonas Smedegaard <dr@jones.dk> writes:
> Could you please elaborate a bit - perhaps I simply misunderstand, and
> there is nothing (big) to worry about here.
In the first case (1-step upgrade), you will end up with an approx.conf
file which will contain:
$ grep pdiffs /etc/approx/approx.conf
# pdiffs:support IndexFile diffs (1)
$pdiffs 1
In the second case (2-step upgrade), the $pdiff line will be missing:
$ grep pdiffs /etc/approx/approx.conf
# pdiffs:support IndexFile diffs (1)
Technically, this is not a big problem since the removed line will
always match a built_in_default value. But it may be confusing, and
that's not a good thing.
...
The more I think about it, the more I feel that changing values during
upgrade is dangerous and should be avoided. Even if the old value is
identical to previous default value.
I think (now) that values written in a config file should be left as is
unless the new version of a model was set up to make them unvalid.
Thus, the upgrade mechanism with config-model would be more simple to
explain (and get accepted).
In this case, only 1-step upgrade would be needed. The old config file
is loaded with new model, only unvalid data are discarded.
And the upgrade operation would be identical to a simple config-edit.
What do you think ?
> Debconf could avoid it by replacing questions like this:
>
> : What setting do you want?
> : a) bananas
> : b) pears
> : c) apples (default)
>
> with questions like this:
>
> : What setting do you want?
> : a) bananas
> : b) pears
> : c) apples
> : d) default (apples)
I fear that most user will not grasp the subtle difference between
option c) and d).
I think the first set of questions are simpler and more straightforward.
> config-* routines can similarly be default-aware.
>
> You are right (if I guess correctly that that is what you mean) that the
> _input_ for both debconf and config-* needs to hint about defaults to be
> most useful, but I suspect that 3-way diff'ing when only a single of the
> 3 parts is potentially user-edited also provides some hinting about
> defaults.
[snip]
> Even if this particular case is invalid when inspecting closer, I hope
> you get the idea.
Yes. That's why I now prefer the simple 1-step upgrade compared to
2-step upgrade (which may try to be too smart ;-) ).
> If you as user agree with a configfile composition but want to make
> sure it does not silently change in a future package update, then you
> need to add some "noise" to the configfile.
ok.
> Such "noise" is most obviously a comment. And comments are ignored by
> config-* routines, right?
yes.
> So how to protect a configfile from silently getting updated by newer
> package releases when the package uses dh_config?
Well, the whole point of trying to merge user customization with
packager change is to automatically (if not silently, mail or log can be
added to config-edit) update the configuration file.
So there's currently no way built in config-edit to "protect" a config
file.
>>> If I understand it correctly, it seems better to me to call it
>>> "configfile_default" and "internal_default".
>>
>>Quite good and closer to the current keywords. I'm quite fond of
>>built_in though. May be "configfile_default" and "built_in_default" ?
>
> Would you mind the singleworded "builtin" instead? It seems cleaner to
> me to have it <binding>_<type> with only a single underscore.
Sure, no problem.
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
Reply to: