[ On Fri, December 18, 1998 at 16:46:56 (-0800), Curt Sampson wrote: ]
> Subject: Re: Package Paths Proposal v2
>
> 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?

Well, normally packages I've seen in pkgsrc that don't upgrade cleanly
(i.e. that don't d.r.t. w.r.t. config files and which might leave
out-dated files behind) are marked specially with "CONFLICTS=" (such as
lesstif which actually probably should *not* mark conflicts because you
might want two versions of the library installed simultaneously,
especially the lib*.so files!).  Presumably pkgsrc packages with
"CONFLICTS=" settings in their makefiles also have "@pkgcfl" in their
PLIST files....

Ideally there would be a pkg_upgrade command that would be able to
discern between simple end-user programs which are merely replaced; and
development tools, which might possibly be renamed to preserve old
programs, headers, and libraries; and packages which are depended on by
other packages for run-time operation (and for which the new files will
not be run-time compatible), such as shared libraries, etc.

However in the mean time "upgrading" by simply pkg_add'ing the new
version, and leaving behind stray files, such as old versions of the
shared libraries, is a "good" thing and generally "Does The Right Thing"
in many circumstances.  Pkgsrc maintainers need to be aware of these
issues, of course, and make logical decisions about how whether a
package should conflict with its previous incarnations, or not.

> 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!

Hold on a minute here.  This kind of confusion I'm talking about
(i.e. over stranded config files) is *FAR* more important than some of
the other minor items that we've been piddling over in this thread (such
as whether or not /usr/pkg/bin is too "strange" for non-NetBSD users to
comprehend ;-).

> 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.

I'm perfectly happy to see these files renamed to indicated their
"stranded" status.

However leaving them un-touched is a very bad thing to do, especially if
a new revision of the same package is installed much later by someone
else, and the old config file could even be so inappropriate when used
by the new version of the package as to introduce a security problem.
Even warning that config files have not removed is a bad idea.  The must
be either removed, or renamed.  (eg. you've got a one-time password
system that may accidentally re-use the same password sequence if the
install re-uses an old config file.  The possibilities for screw ups are
endless, and these are just a tiny fraction of the problems that could
ensue because one administrator is un-aware of a package being deleted)

Pkg_add *did* add them, and it must do something about them when the
package is deleted.

> Because I don't edit and change my binaries. 

Config files are an entirely different type of "object".  They are
intended to be edited.

If, and only if, the pkgtools system were to become paranoid about not
removing any package if any of its component files that didn't match
their original installed contents, then perhaps I could understand your
argument, but so far as I know that's not the way it works today (and
not something I feel would be an important addition to the system).

-- 
							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>