[ On Tuesday, March 2, 1999 at 09:53:47 (-0800), What EES eet man? wrote: ]
> Subject: Re: did the "make reinstall" functionality get slightly broken in 19990119?
>
> [sorry for YELLING but I think that I'm not the only one who thinks that
>  "upgrade" should be an alternative to "remove/reinstall".]

Well, without making the pkgtools a whole lot smarter, an upgrade must
be a remove-old then install-new process.  For a proper upgrade to make
sense the tools would have to know what files are mutable by the user or
admin, and of those files which need to be merged with new changes in
the new release, which cannot be merged and thus represent conflicts
that need manual updates, and of course which can be safely replaced if
they have not been changed in the current installation and which cannot
(and probably more scenarios that I've forgotten).

One of the obvious problems with the current pkgtools philosophy and
policies is that they can screw you just as easily as they might save
your bacon.  If, for example, the config files for the old version are
not deleted (or at least renamed to innocuous names), then they might be
used by the new version and might cause the package to fail without
warning, perhaps even in a damaging way.

I've seen arguments presented which suggest the admin should always
manage the configurations of their systems and the packages installed on
them and "be in the know" of what's going on at all times, but I think
it's safe to say that a package management system gives many people very
different expectations.

Perhaps part of the packaging system should include hooks to a systems
configuration management tool, but of course we're not quite there yet! ;-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>