Re: RFC Debian package upgrade with Config::Model

[Jonas Smedegaard <dr@jones.dk>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Apr 28, 2009 at 09:27:27PM +0200, Dominique Dumont wrote:
>Jonas Smedegaard <dr@jones.dk> 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 
files.


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

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

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

iEYEARECAAYFAkn3brgACgkQn7DbMsAkQLhFuACggs+DB3JefWaGa898oek3Xy3v
EJYAoIllB9JamKkhloGDRT9n7Akrfava
=WpUl
-----END PGP SIGNATURE-----