Re: RFC Debian package upgrade with Config::Model
Jonas Smedegaard <dr@jones.dk> 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.
Agreed.
> ...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)
$pdiffs 1
But this setting is lost when writing customized values (i.e. different
from built_in default values):
$ sudo config-edit -model Approx -dump
max_wait=14
distributions:debian=http://ftp.fr.debian.org/debian -
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
limitation.
> 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
cases here.
>>( 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.
yes.
> 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
> default:
>
> 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
--
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: