* Danek Duvall <danek.duvall at sun.com> [2006-12-14 11:32]:
> 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.
Well, the split is consistent with other environments on the system.
If we're arguing that this is a special environment ("near complete",
rather than "incomplete"), then we get back to having the choice of
PATH=/usr/bin:/usr/gnu/bin
or
PATH=/usr/gnu/bin:/usr/bin
or
PATH=/usr/bin
(since PATH=/usr/gnu/bin would fail to find necessary commands for
system operation) as valid options.
Changing the default PATH and MANPATH settings is possible, but is
seems always to be controversial...
> 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.
So you would have
/usr/bin/seq -> /usr/gnu/bin/seq
and so forth? I suppose I can live with that, although it seems
unnecessary.
> 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.
Conceded in general, but not really a cost given SFW/CCD install
conventions.
> 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?
I had expected /etc/gnu and /var/gnu to be used for some classes of
configuration files.
I believe the proposal was pretty clear about /{usr,var,etc}/gnu for
most files, with the exception of the binaries and the info files. I
need to go look in some */libexec directories to see if its contents
follow the GNU definition in practice.
> 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.
But, of course, the proposal makes all of the non-conflicting commands
part of the path. So the only issue is manual pages. I suppose we
could do a similar split there.
> 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)?
I was debating gnu(5); I'll whip something up.
- Stephen
--
Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems
stephen.hahn at sun.com http://blogs.sun.com/sch/
