[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC Debian package upgrade with Config::Model



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...

> 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...

> 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).

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.

> CipUX would be cool to have such support - and we might even convince 
> upstream to adopt it!
>
> Sympa is a smaller example.  But both Sympa and CipUX are kind-of 
> work-in-progress, so probably bad to use as show-cases on short term, if 
> that is what you are looking for.

Indeed. I'd like to show people that upgrade with config-model is
working and that it's fairly easy to set up.

> 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.

All the best

[1] http://search.cpan.org/dist/Config-Model/lib/Config/Model/Instance.pm#preset_start_()


Reply to: