Re: RFC Debian package upgrade with Config::Model
Jonas Smedegaard <dr@jones.dk> writes:
> I am not sure I understand your logic.
>
> Do you consider it ok _always_ use /var/lib/config-model and _not_ offer
> the alternative of using an extension, and that the reason it is ok is
> that we only want the tool to support Unix-like systems?
No, no. Choice is good.
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.
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.
So, our point of view are similar, even if there are some transient
misunderstandings ;-)
> As I see it, there are multiple tools here:
>
> * config-* invoked when config files are manipulated
> * dh_config invoked at package build time
Yes.
> I believe it makes sense for config-* scripts to be flexible, and work
> even for DOS or other odd systems if possible.
100% agreed.
> I consider dh_config a Debian-specific tool, which we need not care to
> ensure working outside Debian (but we can of course do so if anyone
> provides patches).
Yes.
> 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.
> Or more concretely I imagine...:
>
> * "libconfig-model-perl" extended with binary package "config-utils":
> + contains /usr/bin/config-*
> + asks (priority medium) how to store (default: below /var/lib)
[ scratching my head ] yes, that makes sense
> * "config-utils-dev" created with binary package "config-utils-dev":
> + contains /usr/bin/dh_config
> + contains /usr/share/cdbs/1/rules/config-common.mk
That also make sense.
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).
( 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 )
> See ikiwiki package for an example of how to support automated
> user-level configfile updates during package update (it can't be default
> - local admin must enable this feature, I believe, as it breaks the
> assumption of packaging scripts never manipulating user data).
Interesting :-) This could be applied to existing
libconfig-model-openssh.
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: