[ On Wednesday, September 6, 2000 at 05:07:18 (-0600), Richard Stallman wrote: ]
> Subject: Re: HTML format documentation
>
> In some respect I see the current defaults, starting with `--prefix=\
> /usr/local', as in some way supporting the *BSD systems since that's
> more or less what their heir(7) manual page says.
>
> It has nothing to do with *BSD in particular. People running GNU
> programs on non-GNU systems generally wanted to install GNU packages
> in /usr/local or some other such place, not in /usr. And originally
> the only place to run them was on non-GNU systems.
I was thinking more of the historical perspective, and as far as I can
remember it was indeed BSD which introduced the concept of /usr/local.
It is true that on non-GNU systems it is often not desirable to install
GNU programs in / or /usr. I personally initially kept /usr/local for
non-GNU programs and installed GNU programs in /usr/gnu since at the
time I perceived that there were often two alternatives to existing
native programs and I often didn't want to make a final single choice
amongst the at minimum three alternatives.
> Indeed if the GNU system has similar policies
>
> No, in GNU these programs should not be in /usr/local, because they
> *are* "the system".
Ah, yes, exactly. Except that even the GNU System has add-on
third-party packages and indeed I believe, correct me if I'm wrong, that
it is the practice on GNU systems to use /usr/local as the run-time
prefix of such add-on packages.
> I guess what I'm really asking for is that Autoconf to at first take one
> more step such that it can automatically reset its defaults to those
> necessary to install a package as a `first-class' citizen of the system
> (as you've so aptly described this). I'm not stuck on the idea of using
> `--prefix=/' to select this default,
>
> / is the wrong place for such installation. The normal place to put
> most programs (at least today) is under /usr, not directly under /.
> For example, executables mostly go in /usr/bin, and only a few in
> /bin. So --prefix=/ is generally unreasonable. We certainly should
> not make this the standard way to ask for anything.
But you can't have your cake and eat it too -- i.e. you can't install
something as a system component in /bin or /sbin if you specify
--prefix=/usr and at the same time expect that nothing will ever be
installed outside of where you set $(prefix) to be.
Unless the GNU System also wants to make the leap of eliminating either
/usr, or /bin and /sbin, it's necessary to use (or at least imply the
use of) "--prefix=/" to install packages as first-class native system
components.
What's important here is if course that if you use --prefix=/ to
indicate a native system install then you're implying that makefiles
need to be aware of the differences between filesystem layout in the
native system vs. filesystem layout in /usr or /usr/local or /opt or
wherever; at least if you don't want to end up with /usr/local/usr/bin!
To go off on a tangent for a moment, I would say that given the
historical use of /usr it is by and far the best thing to eliminate /usr
entirely than to go the other way around. I should probably also point
out that by eliminating /usr one gets rid of the differences between
filesystem layout in /usr/local and /(root) too (i.e. you'd only have
/bin and maybe /local/bin).
Unfortunately of course only a "new" system can hope to erase the
mistakes and compromises of the past and eliminate the abberation of
/usr. It is quite possible to do too of course -- Plan 9 did it quite
successfully.
> What I mean by `wider' is that we need to allow for identification of
> files that belong to either "/" (root) and "/usr" groups too. Perhaps
> the following list will give you an idea of what I mean:
>
> bin.files
> usr.bin.files
> sbin.files
> usr.sbin.files
>
> Sorry, you have lost me. I have no idea what those things are.
Perhaps the above discussion will have shed more light. I really don't
know how better to describe the artificial differences between /bin and
/usr/bin, for example. Accomodating their existance is what leads me to
trying to find compromises in
> I think it would also be sensible to add an ability to install even
> architecture independent files in a destination other than where it is
> expected to be found on the final systems.
>
> I don't understand. Would you please be specific?
>
> In the native build
> environment for most *BSDs this is expressed with the make variable
> `$(DESTDIR)'.
>
> That name does not fit our general naming conventions for make variables.
Call it what you will, but that's explicitly what I mean -- a variable
that will provide a prefix where all installation activities will occur
but which will be invisible (i.e. not used) during run time. I use that
name only so that there's an explicit reference to the existing practice
that I'm trying to describe. The idea of $(DESTDIR) is not only what
makes it possible to install a single package in an initially empty
sub-directory (eg. where it can quickly and very simply be gathered up
and transported to some other system for installation and use), but also
what makes it possible for the entire *BSD build system to create a new
release of the system without disturbing the tools and utilities of the
build system. Indeed in its full expression it would allow for full
cross-builds of the entire system.
> I would also make $(exec_prefix) default to $(DESTDIR)
> and to deprecate the use of $(exec_prefix).
>
> This would be an incompatible change, and there is no particular
> benefit in it, so we should not do it.
In the face of using something like $(DESTDIR) there is actually no need
for $(exec_prefix), but by defaulting its value to be the same as
$(DESTDIR) one would provide some backwards compatability.
I think one of the most disconcerting and confusing things about the
current GNU coding standards, w.r.t. builds and installation, is that
there is no clear distinction always made between build-time and
install-time filenames and pathnames and those used at run-time. It
would be one thing to simply ignore the difference and always assume
that files are always installed directly into their run-time locations,
but $(exec_prefix) adds to the confusion because it takes the baby step
of going part way to making a distinction but it does so only for a
single class of files.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
