Geert Hendrickx wrote:
> On Wed, Mar 30, 2005 at 11:13:56PM +0200, Alan Barrett wrote:
> 
>>On Tue, 29 Mar 2005, Johnny Lam wrote:
>>
>>>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
>>
>>I don't care much about the details, but I do think that it should
>>be difficult to accidentally install a new version of a pkg which is
>>incompatible with data files saved by the old version.  Since there's no
>>easy way to tell the difference between installing the new version from
>>scratch or installing the new version after removing the old version,
>>this implies that it should be difficult to deinstall the old version.
> 
> 
> The constraint should indeed be on the deinstallation.  Whether you are
> upgrading to a newer version or just deinstalling db4, that's the step
> where you potentially loose access to your data.  
> 
> Maybe we should make this a more general framework for known-to-be-
> backwards-incompatible packages?  

In my original post, I alluded to the same type of problem being present 
in other packages, e.g. postgresql, cyrus-imapd, subversion, etc., that 
supply their own package-specific dump utilities.  The example warning 
message is suggestive of a way to re-use the same script for other 
packages.  The top and bottom paragraphs of the warning message is 
boilerplate, and the middle paragraph would need to be supplied by the 
package itself.  Also, PKG_FORCE_REMOVE is meant to be a list of 
whitespace-separated ${PKGBASE} values that could be checked by the same 
shell script, which would suggest making it part of the standard set of 
mk/install script fragments.

The implementation is easy, but I don't want us to be distracted by 
implementation details.  I want the discussion to be on whether this 
type of "super-condition" for package removal is something that is 
desirable or not.

	Cheers,

	-- Johnny Lam <jlam@NetBSD.org>