On Wed, 16 Dec 1998, Greg A. Woods wrote:

: > No.  If something wants to replace system binaries in /bin and /sbin, its
: > behavior is spelled out here, via the move-and-symlink item.
: 
: This isn't "easy" to do for some packages, esp. those that compile in
: their paths.  For example GNU Autoconf coding standards don't expect a
: separate /sbin and /usr/sbin, and anyone wanting to replace a system
: binary will have to jump through extra hoops if they're using autoconf.
: For example I've "autoconf'ed" a fingerd replacement.  I still don't
: really know how I'd properly patch that thing to work with pkgsrc.

Its compiled-in path is /usr/pkg/libexec/fingerd (if it needs one!?).

Its install location is /usr/pkg/libexec/fingerd.

It moves /usr/libexec/fingerd out of the way and symlinks
/usr/libexec/fingerd to /usr/pkg/libexec/fingerd.

:  I think anything that expects this to work right iwht pkgsrc will have
: to have additional gunk in the pkgsrc Makefile or some additional
: install script in the files subdir.

You're right about that.

: However if the pkg system is "leveled" out so that it lives, by default,
: in /pkg (with both /pkg/bin and /pkg/usr/bin, for example), then it's
: trivial to install such a package in place of the existing system
: binaries by either pointing "/pkg -> ..", or perhaps temporarily
: setting LOCALBASE=/.

This goes way beyond the intent of the pkg system, which is why my first
move was to strip the `usr' part of /pkg/usr.  The very first complainers
you'll find are those who want pkgs installed in a `regular' fashion in
/usr/local/.

: I.e. if pkg is to follow hier(7) to the letter then it must be a
: *complete* mirror and include $PREFIX/usr/sbin as well as $PREFIX/sbin.

No, it mustn't.  /usr/pkg is structured to follow the model of /usr/local.

-- 
-- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)