On Mon, Mar 08, 2010 at 10:12:53PM +0100, Adrian Knoth wrote:
On Tue, Mar 02, 2010 at 03:00:56PM +0100, Jonas Smedegaard wrote:

From a quick glance it looks to me that you are moving around a conffile in a packaging script. It is tricky to do so properly - an example of what might else happen is users getting confusing questions if they want to preserve or overwrite "their" changes at package update.

Right.

When switching from non-confile to conffile (which seems to be the case here) there are (complex) ways to handle that properly by using ucf instead and hashing the older default config files.

What do you think about the attached patch? Is it worth the effort or should we just simply stick to the dpkg way?


diff --git a/debian/jackd.postinst b/debian/jackd.postinst
index 6cb11b5..9726539 100644
--- a/debian/jackd.postinst
+++ b/debian/jackd.postinst
@@ -7,7 +7,7 @@ CONFIG_FILE=/etc/security/limits.d/audio.conf

db_get jackd/tweak_rt_limits
if [ $RET = "true" ]; then
-    mv ${CONFIG_FILE}.disabled ${CONFIG_FILE} || true
+    ucf --debconf-ok /usr/share/doc/jackd/examples/audio.conf 
/etc/security/limits.d/audio.conf
else
    # user doesn't want RT prio
    mv $CONFIG_FILE ${CONFIG_FILE}.disabled || true


System must not depend on /usr/share/doc, so the UCF master file should be located somewhere else (and that other location can then be symlinked into /usr/share/doc area, that's ok).

Also, it seems you also need to instruct debhelper that it should make an exception for the file and not mark it as a conffile which is otherwise done automagically for all files below /etc (since dh4, I think).



Another more important point is that above is just switching to UCF, not fixing the problem that caused me to use UCF: The file was not treated as a conffile in the past, and that should be dealt with somehow.

Both DPKG and UCF store a checksum of the file as shipped by the package, and if the local file at package update time does not match, it is assumed that the local admin have messed with it and a question is triggered whether local changes should be preserved or overwritten by the file from the package.

DPKG only holds a single checksum which is stored in /var/lib/dpkg/info/ where we are not allowed to "adjust" as now where we want to correct the error of not registering the file in the past.

UCF can hold multiple checksums and we own the list so can do all sorts of tricks. So we can calculate a checksum of one or more file formats released in the past and install with an updated package all theses checksums as "pristine", so that if a configfile matches any of our checksums then the file is treated as package-installed with no local changes, so no question is asked the local admin. And the opposite: if the local admin changed anything then those changes are not silently overwritten - we ask nicely if they should be preserved or not.

The backside of UCF is that with all that power also come the mess of maintaining it ourselves. Something that is done automagically with DPKG.


So...


If interested in UCF then dig deeper: Look for how to adding custom checksums.

Otherwise do the dirty thing of making a debconf warning telling the local user that we've lost track of editing for that file and we now move it aside (idempotently! if already put aside once then don't overwrite with potentially our own failed-during-install file!!) and install a fresh configfile. That new file will then be handled as a standard conffile and we need not worry about it, just make sure to not mess with it any longer.


...or there's the third and even cooler approach: Use Config-Model. More info here: http://wiki.debian.org/PackageConfigUpgrade


 - Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Attachment: signature.asc
Description: Digital signature

_______________________________________________
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Reply via email to