[companion-discuss] Re: [tools-discuss] Proposing /usr/gnu, 4

[Stephen Hahn]

* Rainer Orth <ro at TechFak.Uni-Bielefeld.DE> [2006-05-05 10:43]:
> Stephen Hahn <sch at eng.sun.com> writes:
> 
> >   specific section invocation has been dropped, and the pages returned
> >   to /usr/gnu/share/man.
> 
> >           /usr/share/man/man1gnu
> >                           Manual page section     Stable
> 
> In that case, this is either left from the previous version, or needs some
> explanation what will go there.
 
  It's a leftover.  Will correct.

> I'm otherwise happy with this proposal, but would like to raise one final
> issue (which btw. came up also during a discussion on sfwnv-discuss):
> 
> 	http://www.opensolaris.org/jive/thread.jspa?threadID=8620&tstart=0

  I went and looked at the SFW implementation of binutils.  We are
  already doing a custom install, so the cost of mixing the binary
  locations is not "uneconomical" (quoting myself).  Accordingly, we are
  still debating the purity of a PATH with /usr/bin alone; serendipitous
  discovery suggests that we should put unconflicting commands there.

  I believe this is our major remaining issue.

> How do we handle GNU libraries?  In the specific case of a shared
> libreadline, it would probably go into /usr/lib since it doesn't conflict
> with existing stuff in /usr.  Since there seem to be licensing issues here,
> though, I think it would be useful for this case to provide guidelines on
> how to handle this case.

  (I had a draft case on programmatic licensing once upon a time, but
  shelved it.  Perhaps it's time to dust it off.)

  I agree that a non-conflicting library would go in /usr/lib.  I don't
  think we can separate out /usr/libexec, since JDS and others have
  established precedent (but we will keep /usr/gnu/libexec).

  - Stephen

-- 
Stephen Hahn, PhD  Solaris Kernel Development, Sun Microsystems
stephen.hahn at sun.com  http://blogs.sun.com/sch/