On Sat, 18 Jan 2003, Jim Bernard wrote:

> On Sat, Jan 18, 2003 at 12:12:43PM -0600, Frederick Bruckman wrote:
>
> > Hard-coded paths in X to "/usr/pkg"? That sounds horrible! Why would
> > that be better than setting environment variables?
>
>   A: Because it doesn't require any changes on the part of users or even
> system administrators.
>
>   I guess you're horrified reaction stems from the fact that LOCALBASE can
> be changed?  That is an excellent point, but it would be nice to have some
> convenient way to avoid the need to set environment variables or use kre's
> union-mount trick.  If /usr/pkg were hard coded, that would cover the vast
> majority of cases, and it would still be possible to use the other methods
> to handle the less-frequent cases.  But it's true that it doesn't feel like
> such a clean solution then.

Actually, the clean solution is to install all such packages to
/usr/X11R6, which is what we do. ;-)

>   BTW: I note that /usr/pkg/bin is hard coded in /usr/include/paths.h, so
> there is precedent within NetBSD for doing so.

That's weak. The PR that generated its inclusion only complained that
the paths contained "/usr/contrib/bin", which didn't exist. The commit
message says the defaults are there for the benefit of old
applications which require them, and the comment lists some, but
"login", for example, is built with -DLOGIN_CAP, and so doesn't even
use that anymore, and the fall-back PATH for execvp() is documented in
its man page as "/bin:/usr/bin", also contrary to the comment. It
appear's that the man page is wrong, and that /usr/pkg/bin and
/usr/local/bin really are in execvp()'s default path, horror of
horrors.

"/usr/pkg/bin" should probably be removed from that file, and from the
default system and users path in NetBSD.cf, which was also justified
solely by inspection of "paths.h".

Frederick