Subject: Re: Stopping a common shoot-your-own-foot problem
To: Martijn van Buul <firstname.lastname@example.org>
From: Geert Hendrickx <email@example.com>
Date: 03/30/2005 12:24:32
On Wed, Mar 30, 2005 at 10:04:23AM +0000, Martijn van Buul wrote:
> It occurred to me that Geert Hendrickx wrote in gmane.os.netbsd.devel.packages:
> > On Wed, Mar 30, 2005 at 09:11:19AM +0000, Martijn van Buul wrote:
> >> Running the risk of suggesting something perpetually stupid here:
> >> Would it be possible to teach these packages how to backup and restore their
> >> databases?
> > No, because, as said, these databases could be anywhere on the
> > filesystem, not in a central place like with most SQL servers.
> I understand that db4 doesn't know where its databases are hiding - but from
> the examples given above, I'm under the impression that the packages
> *using* these databases do. db4 doesn't know where cyrus-sasl2 keeps
> its database. But syrus-sasl2 could know that it's in /usr/pkg/etc/sasldb.
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.