Re: RFC Debian package upgrade with Config::Model
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, May 05, 2009 at 05:28:54PM +0200, Dominique Dumont wrote:
>My point is that using /var/lib/config-model is possible and fits FHS
>for most UNIXes. But alternate solution (like .cds files in /etc) will
>be possible.
Ah, I understand your point now. And yes, we agree :-)
>What I want to do is:
>- provide the simplest config-edit command possible to operate config
> upgrade in a sensible way (hence the discussion)
>- offer other possibilities (at the cost of more complex config-edit
> commands)
>
>Offering simple command in most cases will ease the adoption for most
>users.
>
>On the other hand, offering other choice will also please people who
>want more specific behavior.
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.
>> As I see it, the question is if config-* should lookup a chain of
>> config places that might instruct the tool to switch behaviour, or
>> only use commandline options.
>>
>> And if dh_config should produce packaging script snippets with
>> hardcoded options or leave it out to allow overriding on the system
>> level.
>
>Good points.
...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).
>I still need to refine what will be needed in dh_config.
>
>For instance, with all our discussion, I've realised that the 2 step
>upgrades (save with old model and load with new) will be necessary only
>in some corner cases.
>
>In most cases, one command without temporary storage will be enough.
>(I've updated the wiki page)
>
>Temp storage is needed only when default values are changed from model
>N to model N+1. By default values, I mean values that *must* be written
>in the config file (which should not be needed if the application is
>written correctly).
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.
Or did you mean to talk about (in first sentence above) config-* tools?
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. 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. 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 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"?
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".
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
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)
iEYEARECAAYFAkoAsmoACgkQn7DbMsAkQLh/ZQCfWN1dMKQHOVWDTun4SQ6mQQk2
aP8AoIctyTpo3xixuvCYRkuXD46toF7j
=IRe7
-----END PGP SIGNATURE-----
Reply to: