Re: RFC Debian package upgrade with Config::Model
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, Apr 29, 2009 at 05:43:49PM +0200, Dominique Dumont wrote:
>Jonas Smedegaard <dr@jones.dk> writes:
>
>> Even better: Provide a helper tool for packaging scripts to use.
>> That would ease later improvements or corner-case fixups.
>
>You mean a dh_install_config_upgrader based on
>Debian::Debhelper::Dh_Lib?
I just meant plain shell scripts, but dh_* tools are perfect!
>If yes, that's a good idea. I could even add this new dh_ script to
>current libconfig-model-perl package (just like dh_installtex is
>provided by tex-common).
>
>> 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 had ucf in mind - you might want to have a look at that package for
inspiration.
>(Since I've been working with Config::Model, I try to make a clear
>distinction between upstream project developer, Debian packager and
>Debian end user. These are the 3 main kind of people that may interact
>with Config::Model.)
Agreed.
I work with Pure Blends (and even coined that new name ;-) ), where it
makes sense to operate with an additional role between packager and
user: That of a metapackage applying subdistro customization. Real-life
example: A school district in Germany (Rheinland-Pfalz) uses Debian at
some schools. To minimize need of highly skilled systems administrators
at each school they use Skolelinux - a distro based on Debian but with
most install choices pre-answered, and they use outside contractors like
Credativ to be responsible for the deplyment.
Here are the terms that I use:
Upstream → distro → blend → deployment → admin → user
From each point of view, all previous ones are unanimousdly considered
"upstream", e.g. a school sysadmin should not need to care who applied a
"default" - if Debian added a conffile and either Skolelinux or Credativ
customized it, then the sysadmin cannot answer a question popping up
about whether or not to keep changes (as the changes was earlier in the
chain - at sysadmin stage it was "unchanged").
Such puzzle is easier to solve for packages that supports multilayered
configuration. So I suggest that if providing an /etc/$PKG/$config
file, then store your upstream defaults in /usr/share/$PKG/$config and
read in config from all of these places:
/usr/share/$PKG/$config
/usr/share/$PKG/$config.d/*
/etc/$PKG/$config
/etc/$PKG/$config.d/*
...and it would be great if config-model encourages such scheme by
making it easy to apply to packages when adopting the config-model
mechanism.
Does it 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?
>> Even if [ /etc is ] by far the most common, config (or config-like)
>> files might exist in other locations, like /boot. So I suggest to
>> instead use /var/lib/config-model/upgrade/etc/approx/approx.cds for
>> same example.
>
>Good point.
>
>I'll add these points in the package upgrade wiki page.
>
>Jonas, do you maintain packages that would benefit from using
>Config::Model during upgrades?
Certainly there must be some among the 80+ packages I am directly
involved in maintaining.
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.
Icecast2, perhaps?
Or that pesky little semi-official configfile in libc-client?
- 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)
iEYEARECAAYFAkn5SwYACgkQn7DbMsAkQLjNuwCeP6UEt1qWfxsu4AxSqZZ2kDE6
198AnROz2bTEZErE0BVLs/sHztm9zilt
=+SMt
-----END PGP SIGNATURE-----
Reply to: