Re: RFC Debian package upgrade with Config::Model
Jonas Smedegaard <email@example.com> writes:
> If you mean offering _different_ commands for complex use then I see
> no need: Provide a single set of commands, let them work sanely with
> no options provided, and allow complex stuff through options.
> ...and my opinion (sorry for not providing that before:
> Yes, config-* tools should come with a configfile and support
> multilayered configfile support.
> No, dh_config should generate snippets that invoke config-* tools
> without options (i.e. use defaults of the target system).
> It might make sense for a dh_config option that is passed on to config-*
> (i.e. to _optionally_ allow dh_config to force specific behaviour on the
> target system).
All this makes senses. A lot of details need to be figured out.
> Beware that you cannot at packaging time (when dh_config is used) be
> sure what version of a package is being upgraded from. So the
> dh_config routine needs to always include a snippet that supports
> complex changes.
Which means providing 2 step upgrade (config-edit saves customised data
with old model and config-edit loads them with new model) in all cases.
This will work but require temp storage in /var/lib/config-model (or
elsewhere depending on config::model config.)
> Or did you mean to talk about (in first sentence above) config-* tools?
I hope I clarified above.
> Oh. This also makes me wonder: do you take distinguish between default
> and choice of setting a value that happens to be the default? Imagine
> an application having some internal default for an option, this option
> isn't declared in the packaged configfile, but the user adds it to the
> configfile with same value as is the default.
Currently, config-edit adds the value in the config file:
$ sudo config-edit -model Approx -ui none pdiffs=1
$ grep pdiffs /etc/approx/approx.conf
# pdiffs:support IndexFile diffs (1)
But this setting is lost when writing customized values (i.e. different
from built_in default values):
$ sudo config-edit -model Approx -dump
Hence this setting will be lost on 2 step upgrades but kept on one step
upgrade (this lack of consistency may be construed as a bug...).
> Then the internal default changes - is the configfile value then
> changed or preserved?
> Debconf has such limitation: if an option is "seen" and value equals
> default value, then it is unknown if the value was explicitly chosen or
> just "left at its default" - so on later upgrades with default changing
> it is impossible to figure out if the value should be silently changed
> or silently kept.
Short of designing telepathic tools, I don't know how to avoid this
> Only for "unseen" options is it sane to assume that the value is
> "left at its default". But then again, the seen/unseen flag is only
> temporary - debconf is only a caching mechanism, not a storage system.
I'd say that silently changing a default value written in a file or not
will depend on the side effect of this change. It may be a decision
better left to author or packager or blender. We need some real life use
>>( I realise now that the element properties names 'default' and
>>'built_in' are not well choosen. 'default_explicit' and
>>'default_implicit' may be more easy to grasp ... The first implies a
>>default value that must be explicetely written in config file. The
>>second is a default value that built in the application and which does
>>not need to be written in the config file )
> Hmm. Isn't it superfluous to use "default" when all but user
> customizations are some kind of "deault"?
Well, there's some historical cruft here. 'default' came in first, then
'built_in' was added. I did not see the ambiguity until much later :-p
> It seems to me that what you call "default_implicit" is upstream
> embedded default and "default_explicit" is packaging customization.
> 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" ?
In any case, changing the keywords is relatively easy: all existing
models will be upgraded with minimal work by Config::Model::Itself.
> Or more generically: Clarify where and to whom it is a default.
> I.e. at what part of the upstream-me-downstream chain was it declared a
> author → packager → blender → installer → administrator → user
This will require to refine the mechanisms that will be needed to
"specialize" the config chain. I'll deal with this later.
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