Subject: Re: Stopping a common shoot-your-own-foot problem
To: None <firstname.lastname@example.org>
From: David Brownlee <abs@NetBSD.org>
Date: 03/31/2005 00:49:55
On Wed, 30 Mar 2005, Geert Hendrickx wrote:
> On Wed, Mar 30, 2005 at 12:24:32PM +0200, Geert Hendrickx wrote:
>> This could get really difficult. For example: mail/spamprobe is a
>> spamfilter which uses db4. It has no config-file, it's just called by
>> procmail (or any other mailfilter) with specific command-line arguments.
>> It has a default database location (~/.spamprobe/sp_words), but I am
>> also using non-default locations ("spamprobe -d $location") because I
>> use different databases for different mailboxes. So the upgrade-process
>> should go find each users .procmailrc (which can themselves be in
>> non-default locations), parse it to try to find out where the users
>> spam-databases are, etc... This could get really difficult. :-)
>> I much prefer the warning-and-break-unless-some-variable-is-set-method.
> Another argument is that I wouldn't like important databases to be
> dump-restored with incompatible versions of db4 in an automated way.
> I wouldn't mind taking some time to do that manually. :-)
Maybe a set of packages, each providing a dump tool for a
given db4 format? So if you get into the situation you can
always add a package in to run the dump, without breaking
your new setup and anything that has started to depend on it
David/absolute -- www.NetBSD.org: No hype required --