Re: RFC Debian package upgrade with Config::Model
Hello
Jonas Smedegaard <dr@jones.dk> writes:
> 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?
It's often both. Imagine a desktop user, who just switched from
Windows. He's the end user and has to do the admin for his machine, but
he does not have the skills (yet?).
For this kind of people, you don't expose choices unless absolutely
necessary.
[ for the record, I indeed do the admin for my mother-in-law, but not
for my brother, who just switched from Windows to Ubuntu ;-) ]
>>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).
There's indeed no need.
> 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).
I certainly don't want to close the door regarding multi-layered config.
> 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!).
Agreed.
> 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.
Understood.
I can either:
- tweak config-edit so that temp files for upgrades are stored in
/var/lib/config-model, something like:
config-edit -save_for_upgrade # creates temp file
config-edit -upgrade # use previous temp file
- arrange for the dh-upgrader script to store temp files in
/var/lib/config-model
First option is probably the best as it would be valid across distros.
Thoughts ?
> (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)
I'm all ears.
All the best.
PS: I've updated http://wiki.debian.org/PackageConfigUpgrade with the
first results of our current discussion. Some FIXMEs are still left.
--
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: