I'm considering adding a DEINSTALL script to databases/db{,3,4} that 
would prevent deinstallation of the package unless some condition is 
met, e.g. a shell environment variable is set.  Basically, I'm picturing 
something like this:

user> cd /usr/pkgsrc/security/cyrus-sasl2
user> make update
...
===> Deinstalling for db4
Running /usr/sbin/pkg_delete -K /var/db/pkg db4-4.2.25
===================================================================
WARNING * WARNING * WARNING * WARNING * WARNING * WARNING * WARNING

You are trying to remove db4-4.2.25.

If you are updating to a newer version of db4, please make sure
that you have already used the db4_* tools to dump your existing
Berkeley DB 4.x databases as the newer version of db4 will not be
able to read the existing databases without reloading them.

If you are sure that you would like to remove db4-4.2.25
at this time, please add "db4" to PKG_FORCE_REMOVE in your
shell environment, e.g. in Bourne-compatible shells:

	PKG_FORCE_REMOVE="${PKG_FORCE_REMOVE} db4"
	export PKG_FORCE_REMOVE

WARNING * WARNING * WARNING * WARNING * WARNING * WARNING * WARNING
===================================================================
*** Error code 1

Stop.
make: stopped in /usr/pkgsrc/security/cyrus-sasl2
user>

I know the cons of an approach like this: it puts barriers in the way of 
users that script their own package maintenance procedures.  However, 
I'm weighing this against one of the most common ways you can lose vital 
data when updating your packages via pkgsrc -- by inadvertantly removing 
your only copy of db4 when you were just updating some downstream 
dependent of db4, e.g., update cyrus-imapd and suddenly lose access to 
all of your existing Cyrus IMAP mailboxes because they are in a format 
incompatible with the newer db4 package.

Conceivably, the same type of DEINSTALL script could be added to other 
packages that are sensitive to the dump/reload problem, e.g., 
postgresql, cyrus-imapd, subversion-base, etc.

I have no patches to implement these yet.  I'm just trying to get a 
sense of what users and developers want to do here.  Quite possibly the 
answer may be to do nothing more than we do now, but I'd like to get 
confirmation from the community if this is the case.

	Cheers,

	-- Johnny Lam <jlam@NetBSD.org>