Hi Danek,

Are you suggesting that we install everything to /usr/gnu and symlink
everything that is an interface and is non-conflicting to /usr?
That's fine by me, but we need to be careful when identifying what
is an interface.

Laca

On Thu, 2006-12-14 at 11:32 -0800, Danek Duvall wrote:
> 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?



Reply via email to