On Sat, Jan 18, 2003 at 04:31:25PM -0600, Frederick Bruckman wrote:
> On Sat, 18 Jan 2003, Jim Bernard wrote:
> >   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. ;-)

  Well, that's clean from the standpoint of managing app-defaults, but it's
very unclean from the standpoint of managing X11 installations.  With
xpkgwedge in place, one can easily keep several X11 builds in /usr/whatever
and simply change a symlink to switch from one to another if one proves
to have problems.  (For a short time my two best X builds broke two different
important applications, and I had to make several switches between them; the
ability to simply swap symlinks was extremely helpful.)  If packages
contaminate /usr/X11R6, you always have to take some risk that if something
breaks when you update X11, you may have to go to considerable effort to
revert to an earlier version.  And keeping several versions around would be
a nightmare, with each having its own particular set of packages contaminating
it, only the most recent of them actually matching the contents of PKG_DBDIR.

  It's not a big deal to me to stick with xpkgwedge, but I do think it
would be nicer not to have to use it to keep packages from contaminating
X11 installations, and I believe it would make life easier for newcomers.

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

  Actually, it's rather convenient for users of multiple OS's to have
standard paths like that provided by the system by default.

--Jim