Subject: Re: Stopping a common shoot-your-own-foot problem
To: David Brownlee <abs@NetBSD.org>
From: Johnny Lam <jlam@NetBSD.org>
Date: 03/31/2005 12:43:24
David Brownlee wrote:
> 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
This is a nice solution. If I were to implement this, I would create a
set of packages -- dump-db4225-4.2.25, dump-db430-4.3.0,
dump-db435-4.3.5, etc -- for each minor version of db4 that passes
through pkgsrc, and each of these packages would contain a
statically-linked db4_dump-4.2.25, db4_dump-4.3.0, db4_dump-4.3.5, etc.
binary. The only problem I have with it is just that it's simply a lot
of work. This is a code maintenance issue more than anything else, but
I don't have the time to devote to this type of maintenance.
I also phrased the problem in such a way that it's clear this issue of
needing to warn of catastrophic data-loss extends to packages like
PostgreSQL or Subversion that have their own package-specific data-dump
utilities that may need to be run before the package is de-installed.
This isn't handled by the db4_dump solution that you suggest above, so I
think we still want some sort of general solution that can be used by
those other packages.
-- Johnny Lam <jlam@NetBSD.org>