Rainer Orth writes:
> Maybe, but in my opinion dealing with a whole GNU package in one consistent
> way (i.e. completely in /usr/bin or /usr/gnu/bin) is more consistent with
> user expectations than spreading it across different directories.
Agreed, which is why I think the proposal ought to be (in fact)
/usr/bin. The links are provided under a different name in
/usr/gnu/bin as a _convenience_ for those who use $PATH to select
preferred environment, not as an actual install target for ./configure
--bindir=.
The solution I see is:
- install using /{usr,etc,var} as base directories for
everything.
- if it conflicts with objects we deliver or likely will
deliver (or, per ARC review, just has an objectionably
"generic-looking" name), then rename it as part of the
packaging, and provide a link using the original name under
/{usr,etc,var}/gnu.
- the same policy goes for all of it -- binaries, man pages,
info files, libraries, data files; the works. It is all
installed in its natural location in the system.
As a bonus, this gets us the /usr/lib/64 linker automagic goodness for
free, which we (unfortunately) don't otherwise get if the libraries
are placed anywhere else.
This leaves the purists who would like to see /usr/bin as a bastion of
SysVishness out in the cold. But they're there already, as there are
already both GNU and BSD things in /usr/bin, so it doesn't seem to
matter.
Obviously, different distributions may do otherwise. (For real SysV
goodness, you probably have to bring back the 14-character file name
limit. ;-})
--
James Carlson, KISS Network <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
