On Mon, 31 May 1999, Matthias Scheler wrote:

> On Mon, May 31, 1999 at 03:36:53AM -0500, Frederick Bruckman wrote:
> > > Ok. But what I want to avoid is that this configuration file will remain
> > > there even after the package is completely gone.
> > 
> > But isn't that exactly the point of doing it that way? You want to be
> > able to upgrade without wiping out all your config files, don't you?
> 
> That's why I said "completely gone". You might e.g. want to switch from
> Apache to something else.

As a command line option to pkg_delete, yes, but please not by
default. I might like to upgrade netatalk, e.g., without having to
collect all my type/creator codes again. There are already a couple of
files in my /usr/pkg/etc that are over a year old. As years go by,
it's not likely that I would ever be able to reconstruct them.

I do see the problem, where programs might try to use incompatable
files from previous versions, or even from an entirely different
package. I suggest that a package that's subject to that problem can't
reliably count on all other packages to stay out of it's way. The
colliding package might still be installed, or it may have been
installed some time ago, before the current handling was in place.

How about this idea. Have two ways of handling config. The default
would be to install an example to /usr/share/examples or a
subdirectory thereof, then copy it to /usr/${LOCALBASE}/etc or the
appropriate subdirectory _only_ _if_ the config file(s) don't already
exist. For packages that are known to collide with a previous version,
or another package, force the config file(s) to be written to etc, but
always after backing up the old configs to ${filename}.old.

The present system doesn't allow installed files that have been
modified to be deleted automatically. Perhaps the "@comment MD5:" in
+CONTENTS could be overloaded with a "@comment CONFIG". This would
prevent any previous pkg_delete from deleting the file (right?), but a
new pkg_delete could delete it unconditionally in response to a
command line option. We could even have a -i option, that would prompt
before deleting. Another benefit of tracking configs is that you would
then have a way of figuring out which configs are for which package.