The proposal to split GNU packages between /usr and /usr/gnu sits oddly
with me.  I'm not sure I have a convincing argument against it, but I'll
say my bit (which applies only to commands and libraries, and nothing
else).  I think it'll be a bit confusing to have only part of, say,
coreutils available in /usr/gnu.  People looking there may wonder why we
only shipped part of it, or if they did discover the split, why we did
that.  I think that presents a case for having everything in /usr/gnu.

I think having these utilities in /usr/bin is useful, but my inclination is
to recommend that the canonical location is /usr/gnu, and that the entries
in /usr are for convenience only, and should be treated as Volatile.  I
don't expect that we would often remove them in favor of a new, native
Solaris command, but I think it might be useful to reserve the right to do
so.

It'll also probably be easier to say

    ./configure --prefix=/usr/gnu --sysconfdir=/etc/gnu 
--sharedstatedir=/var/gnu

and do a simple install than to use the same configure (or maybe
--prefix=/usr), and then cherry-pick bits of the built source tree or
install image to put in random places.

The non-conflicting separation bit also raises the question of things that
aren't commands or libraries -- should they go into /usr if there's no
conflict?  If, as per the current spec, some commands go into /usr and some
go into /usr/gnu, where do files destined for .../share or .../libexec (for
example) go -- where their utilities go, or into /usr/gnu, or into /usr, if
there's no conflict?  Perhaps a bridge we don't need to cross yet: what if
there's no conflict for the utility, but there is for the support file?

My second major concern is in regard to manpages.  I think that all man
pages need to be available without any manpath twiddling, as I believe that
manpages are a primary means of discovery.  I don't care too much how this
is done -- whether we modify the man utility to include knowledge of
/usr/gnu/man, or whether we add <sect>gnu sections to the existing manual,
or something else.  But I'm afraid that if all of these utilities aren't in
people's PATHs (and similarly with the libraries), and the man pages aren't
immediately available, then people will think we don't have them, which is
one of the biggest problems with /usr/sfw today.

Also, is there going to be a top-level manpage for this project?  Something
that might tell you to put /usr/gnu in your path, and how it should be
done, and why?  Perhaps an addition to standards(5), with a new link from
gnu(5), as we have for XPG(5)?

Danek

Reply via email to