[SCM] Debian packaging for jack-audio-connection-kit branch, master.jackd2, updated. debian/1.9.4+svn3842-2-24-g6b0dbd2

[Jonas Smedegaard]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20100308/4261fffe/attachment.pgp>