Re: RFC Debian package upgrade with Config::Model
-----BEGIN PGP SIGNED MESSAGE-----
On Tue, Apr 28, 2009 at 09:27:27PM +0200, Dominique Dumont wrote:
>Jonas Smedegaard <firstname.lastname@example.org> writes:
>> One comment: If I read it correctly, you use .cds as extension for
>> temporary dumps at package upgrades.
>Yes. cds is supposed to mean "Config-model Dump String", but the
>extension can be anything else.
>> Tools like etckeeper, backup routines and IDS'es like integrit might
>> get annoyed by those.
>Are these tools annoyed by .dpkg-new or .dpkg-old files ?
No - etckeeper ignores this pattern: *.dpkg-*
I remembered wrongly before: integrit simply avoids all of /etc by
default (which might be a reason to use a different IDS!).
I remember several times such patterns mentioned in changelogs, however,
but realize now that those were most prbably ordinary packages using
run-parts like constructs on the _own_ conffiles, and then needing to
avoid including dpkg cruft. Such packages are off course no problem: if
a package choose to use cds, then it also care about avoiding its temp
>One advantage of storing dump file in /etc is that reviewing the
>upgrade is much easier: the config file and the dump file are side by
>side. But I agree that it's a small advantage.
>> I recommend either mimicing a common extension
>A common extension like '~' ? Do you have other extensions in mind ?
"~" is a bad choice: It is a de-facto standard for editor temp files,
and editors might ignore and overwrite it without warning. We would
want the files to be cared more about, i.e. only be deleted when
explicitly choosing to do so, and only silently overwritten by same cds
I was thinking e.g. dpkg-cds or something. But I dislike it, as dpkg-*
really should be for dpkg use only.
I would prefer using a separate tree structure.
>> or storing in a tree below e.g. /var/lib/config-model.
>Actually, the file name for the temporary dump is specified in the
>package scripts (prerm and postinst). If many packages use
>Config::Model to perform upgrades, many dump files may be written
>during massive upgrades. Having a consistent naming policy to avoid
>clashes will be very important.
Even better: Provide a helper tool for packaging scripts to use. That
would ease later improvements or corner-case fixups. You could then
even make it a user choice if it should use a .cds extension or a
separate tree structure. :-)
>May be something like, mimicking /etc structure under
>/var/lib/config-model/upgrade (*) would work. This way, approx dump
>file would land in /var/lib/config-model/upgrade/approx/approx.cds
Even if by far the most common, config (or config-like) files might
exist in other locations, like /boot. So I suggest to instad use
/var/lib/config-model/upgrade/etc/approx/approx.cds for same example.
>(*) using upgrade subdirectory will let me use other kind of storage in
>/var/lib/config-model, like user annotations ...
Ah, makes sense.
* 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)
-----END PGP SIGNATURE-----