On 7 16, Bill Sommerfeld wrote:
> Doing something like this is .. scary .. particularly when it comes to
> doing something sane when either upgrading the OS or deinstalling the
> package.
> 
> We may be much better off if it's possible to:
> 
>   a) hack the base install to move the "replaceable" binary to a unique name
>      (and leave a link behind)
>   b) hack the package install to do the rename if not yet done, and
>      then create/replace the link with one pointing at the base install.

  If you put the pkg files into /, /usr, then the OS installation and
the pkg installation need to cooperate with each other (which seems rather
messy and prone to breakage), and the decision as to which takes precedence
at any given installation of either the OS or the pkg cannot be made in an
absolute sense; i.e., only the _person_ doing the installation, not the
Makefile or pkg tools can know whether the current installation should
override the previous one.  Given that, it seems cleaner to put the pkg
into /usr/pkg, which still leaves the precedence decision up to a person,
but retains two important additional points of flexibility:

  1) the precedence can be changed without deinstalling or reinstalling
     anything

  2) different users on the same system can make different choices as to
     the userland binaries they prefer to use

A potential problem with the latter is that if there are shared libraries
that are significantly different in the two cases, they will have to be
either named or versioned differently so that the each set of binaries
gets the right libraries loaded.