Re: RFC Debian package upgrade with Config::Model
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, May 02, 2009 at 12:11:13PM +0200, Dominique Dumont wrote:
>Jonas Smedegaard <dr@jones.dk> writes:
>
>>>> You could then even make it a user choice if it should use a .cds
>>>> extension or a separate tree structure. :-)
>>>
>>>You mean a Debian packager choice?
>>
>> No, I mean user choice.
>
>I'm puzzled ... I don't see why you'd want to expose end users (I count
>my mother in law in that group ;-) ) to this kind of implementation
>detail...
Do your mother _admin_ he own machine(s) then she _might_ want to tweak
that option (and she might not - it is only an _option_).
I suspect that you are using the term "user" for two different things:
I use these terms (refined since last email):
author → packager → blender → installer → maintainer → user
You use these:
upstream → packager → user
It seems obvious to me that upstream=author packager=packager, but with
"user" do you then mean a non-admin person or someone installing and/or
maintaining the system?
>> I had ucf in mind - you might want to have a look at that package for
>> inspiration.
>
>Having looked at /var/lib/ucf, I think you're right. Storing dump files
>in /var/lib/config-model would make sense. Let me see if I need to add
>more options to config-edit or create a new config-upgrade command...
...and if you agree, then perhaps there is no need for also supporting
storage below /etc. This would simplify greatly, as you would then not
need a config file (with multilayered config support).
You might still want to support multilayered config for other parts of
the tool: Imagine the packager describing only a subset of upstream
supported config options, and a blender or installer needed to change
different options - would be cool if the blend could extend config-model
(and augeas lense).
>> Does [ some kind of multilayered configuration ] make sense? Or do
>> you think that perhaps even if it make sense, it is too much outside
>> the scope of config-model and confusing to include in e.g. examples?
>
>It does make sense, but config-model must also stay as simple to use as
>possible for usual cases (e.g. upstream -> Debian packager -> user).
Yep. Above blend need is really a complex case, so better postpone such
functionality for later.
In other words: I agree to avoid multilayered config support alltogether
for config-model for now (but not for too long: Skolelinux most likely
would want it dearly for Lenny+1 if at all possible!).
>With the notion of config model and config data, the multilayered
>config could either be applied at model level (with a mechanism yet to
>define) or at data level.
>
>The latter is already (partially ?) implemented with the notion of
>"preset" data [1]. Preset is a way to define default value without
>altering the config model. I do not know if the preset notion can be
>useful in "pure blends" context.
I think so (I have not looked closely yet).
But when even the smallest show-cases explicitly declare file locations
to read from, not only config-model but each and every package using it
must care about looking in additional places for possible add-on
"underlay" config files. That's the reason I propose to offer some
wrapper that takes care of that.
>> Icecast2, perhaps?
>>
>> Or that pesky little semi-official configfile in libc-client?
>
>I think we should start small, with simple and slowly evolving
>configurations. I'll be more able to help if I clearly understand the
>purpose of the software, so icecast2 is probably the best candidate.
(I might come up with an even better candidate: while I am involved in
packaging icecast2 I do not really use it myself, so would not really
know what options would be relevant to handle)
- 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)
iEYEARECAAYFAkn8Ox8ACgkQn7DbMsAkQLiISQCfXsFdjXqNyevtfUUMcbXTEjz0
WBQAoKFdtOvaiGmTxtctL2Bbln7g9atw
=2hHs
-----END PGP SIGNATURE-----
Reply to: