On Thu, 17 Dec 1998, Greg A. Woods wrote:

> Well, I'm not so sure how/if/why it works, but it seems that for some
> packages, at least those you install from pkgsrc and which only register
> themselves with pkg_add, you can indeed just install newer versions of a
> package on top of older versions.

That sort of thing is a bad idea, because you might get left with
old binaries still kicking around when binaries move. Remember the
upgrade problems people experienced when we moved nfsd from /sbin
to /usr/sbin?

> I know what you mean, but if you're going to be deleting the binaries
> then either you should delete the related config files, or at least
> rename them to something that shows they are no longer used or active so
> that someone doesn't come along later and get confused by their presense.

That's a nice thought, but that confusion is a much smaller price
to pay than deleting unique user data on some ocassions is. Also,
you don't know, when pkg_delete is run, that a pkg_add isn't going
to be run right after to put in the new version of a package!

My rule is that pkg_delete should *never* delete anything that
pkg_add did not add. If /etc/named.conf was added and is still
exactly the same (same MD5), I could see removing it. If it's
different, that is no longer a file that pkg_add added to the
system, it's a different file that someone else put there. Since
someone else put it there, someone else can delete it.

> Somewhere along the line some trust has to be granted.  If you don't
> trust the pkgtools to play with your config files then why do you trust
> them to play with your binaries?

Because I don't edit and change my binaries. 

cjs
--
Curt Sampson  <cjs@cynic.net>   604 801 5335   De gustibus, aut bene aut nihil.
The most widely ported operating system in the world: http://www.netbsd.org