Re: RFC Debian package upgrade with Config::Model
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, May 07, 2009 at 01:54:36PM +0200, Dominique Dumont wrote:
>Jonas Smedegaard <dr@jones.dk> writes:
>> 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.)
Ok.
If you are not experienced with ensuring idemotency of packaging
scripts, I recommoned you to look closely at the source of the ucf
package. It is fairly detailed commented, written in shell and perl,
and handles a task similar this one. And it is written by Manoj
Srivastava, who might be difficult to read sometimes but generally knows
quite well what he is doing.
>> 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...).
Not sure I understand above in detail, but that last sentence worries me
:-(
Could you please elaborate a bit - perhaps I simply misunderstand, and
there is nothing (big) to worry about here.
>> 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.
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)
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.
>> 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 believe apache used to use latin1 encoding by default, and when
apache2 was introduced in Debian the _packaging_ used same encoding,
even if upstream default for apache2 changed to utf-8. Later the
packaging default changed to be same as upstream.
There was several ways for the user to change that setting. Either
changing at same place as was declared by the package, or overriding at
other places.
If the user happen to declare it the exact same way as was later
expressed by the packaging, then I believe the packaging upgrade
routines could not distinguish if the user setting of utf-8 was
deliberate or should be absorbed as being "please follow packaging
default from now on".
Even if this particular case is invalid when inspecting closer, I hope
you get the idea.
Or even simpler - forget debconf: The fundamental logic of conffiles
handling internally in dpkg is to assume that a configfile that matches
the md5sum of the configfile of the old package was unaltered (which is
true) and thus wants to follow packaging defaults (which might not be
true). 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.
Such "noise" is most obviously a comment. And comments are ignored by
config-* routines, right?
So how to protect a configfile from silently getting updated by newer
package releases when the package uses dh_config?
>> 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.
>In any case, changing the keywords is relatively easy: all existing
>models will be upgraded with minimal work by Config::Model::Itself.
Yes. I understand that :-)
>> 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.
ok
Regards,
- Jonas
- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkoDF2IACgkQn7DbMsAkQLgmpwCfZ1t5+nb3J0i7LFMr/kFodqaK
hrMAnjU+2GU63GblgTZDmG7l92d2GL5f
=ydHh
-----END PGP SIGNATURE-----
Reply to: