[ On Saturday, September 2, 2000 at 22:57:04 (-0600), Richard Stallman wrote: ]
> Subject: Re: HTML format documentation
>
> Developers can make all sorts of mistakes. The mistakes just have to
> be fixed. Developers who ignore or misunderstand the rules for what
> files should go where can put files in the wrong places no matter what
> the rules are.
>
> So I don't think this is a valid argument.
I can certainly see your point! :-)
> It could be useful for autoconf to know the defaults at least for some
> kinds of systems. We don't necessarily have to undertake to keep up
> with them for all the systems anybody uses, though. That could be a
> lot of work; let's not rush into such a large commitment. We should
> start by supporting the GNU system and its variants, the GNU/Linux
> systems. Then we could support the other free systems, *BSD.
I agree very much that it is a significant commitment and it certainly
should not be taken lightly or rushed into. I'm not sure it's a lot of
work, especially given the extent to which Autoconf is used now, and the
flexibility this affords. What is large and complex is probably the
task of educating developers.
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. Indeed if the GNU
system has similar policies then both systems can be supported with the
same default settings in GNU Autoconf (and it would seem that is the
case today). As you say in your reply to my comment about giving up on
`--prefix', there's no reason a new option couldn't be defined that
selects whether the package is to be installed as a native component, or
as an add-on in some "standard" location.
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, though that does seem to be an
obvious and unmistakable hint that an installer could give to indicate
this intention.
There are some other niggling variants that I've raised as issues that
bug me, and in some way (at least to my satisfaction) they would be
dealt with as part of this task of supporting defaults suitable for *BSD
with `--prefix=/' (eg. $(prefix)/info vs. $(prefix)/share/info, or
$(prefix)/etc vs. /etc). These issues could of course be solved easily
by allowing site managers to define a new type of platform description,
or override an existing one, that would make these distinctions.
To do this we would no doubt have to define an even wider taxonomy of
files so that developers could be guided into classifying their
installable files, leaving Autoconf and standard template Makefiles
(perhaps as generated by Automake) to provide the mechanisms for
installing these files in the appropriate directories.
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
(of course this doesn't mean I'm totally giving up on my idea of
eventually eliminating "/usr"! :-)
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. In the native build
environment for most *BSDs this is expressed with the make variable
`$(DESTDIR)'. I would also make $(exec_prefix) default to $(DESTDIR)
and to deprecate the use of $(exec_prefix). This helps to eliminate any
confusion developers and installers might have about whether a
configuration variable can be used within a program to refer to some
other package component at runtime or not -- i.e. in general all
variables not including $(DESTDIR) can be used at runtime too, and the
only major exception being perhaps those pointing at config files. For
the latter it would be good to give developers guidance in how to
separately identify the location of config files and their base names
such that $(confdir) [or whatever] can be used to identify their
location at runtime, but $(DESTDIR)/$(examples) might be where they are
installed.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
