Subject: Re: bin/3563
To: Michael C. Richardson <mcr@sandelman.ottawa.on.ca>
From: Erik E. Fair <fair@clock.org>
List: current-users
Date: 07/06/1998 11:49:54
I reread the PR. The PR talks about installation, not "make all".

You can as any user:

	cd /my/source/tree && make

right now, and everything will compile, provided that you have write access
to all the directories and files in that tree. This, of course, does not work
for "make build" or "make distribution" because those targets do installs of
include files and libraries and such.

I'm curious to know how you propose to put the correct file ownerships in
place *after* installation of those binaries, if not done at install-time?
There are quite a few setuid binaries which won't even work without the right
owner or group on them.

As a secondary issue, I have found that environment variable use for program
behavior of the type you suggest violates the Principle of Least Astonishment.
For programs whose behavior you wish to modify on a permanent basis (e.g.
less), it makes sense. For options that are more transitory in nature, it is
better to require that a command line option be used, so that the behavior
does not persist beyond a single invocation. I believe that the behavior you
seek from "install" is in the latter category.

For what you want to do, the /usr/share/mk/* files should be whacked for an
option not to set the ownerships of the files installed. However, without a
good answer to the question of how the ownerships get set later, I don't think
it's a good idea.

In some sense, I believe you're seeking a way to do builds in a "sandbox" on
a production system; maybe some chroot'd environment? Personally, I use
dedicated build systems, which, if trashed by unfortunate source code or
Makefile changes, are annoying to put back to rights, but not critical. I
believe that this is the prevailing practice of most of the NetBSD developers.

This is by no means a final answer to this PR; I am but one developer, and
you now have *my* opinion. You may be able to find someone else to work on
this problem. I'm still willing, if my questions are answered. I'm not trying
to be difficult - just thorough.

	Erik E. Fair    fair@clock.org