Is /usr/gnu/bin really intended for pure gnu licensed utilities? If so, where do we put tools which aren't pure and stable enough for Solaris and yet aren't gnu? One example is the VIM (vi improved) editor, it isn't gnu licensed but it isn't 100% compatible with Solaris /usr/bin/vi. Will we have a home for such tools? Does it really make sense to separate gnu licensed tools from non-gnu tools which are commonly installed on linux? If we intend for /usr/gnu/bin to be only for gnu licensed stuff, then IMHO we will still need /usr/sfw/bin and I'm not sure we will have solved any more problems then we've created by adding yet another collection of stuff that newcomers to Solaris will have to remember to put in their default path in order to make it behave more like the O.S. they are crossdeveloping for or migrating from.
Rainer Orth wrote: > Stephen Hahn writes: > > >>> 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. >> > > Indeed. See my reply to Bart's mail for further arguments favoring purity. > > >>> 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.) >> > > That would be useful. > > >> 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). >> > > Fine with me. I can live with the established > > /usr/lib/<package>/<helper prog or shared object> > > just as well as with /usr/libexec, so introducing the latter seems > unnecessary for OpenSolaris. I think we should say so explicitly in the > /usr/gnu proposal since for non-conflicting packages the libexecdir suffix > will change compared to conflicting ones. > > Rainer > > ----------------------------------------------------------------------------- > Rainer Orth, Faculty of Technology, Bielefeld University > _______________________________________________ > desktop-discuss mailing list > desktop-discuss at opensolaris.org >
