On Fri, Apr 28, 2006 at 02:11:40PM -0400, Laszlo (Laca) Peter wrote: > Well, maybe that's the right answer to John's question. However, > it sounds just like /usr/sfw under a new name and that didn't seem > to solve our "problems" (partly because somehow we combined that with > g-prefixing the executables).
/usr/sfw was a mistake. It had nothing to do with "personality" and everything to do with keeping that Evil Freeware out of the default path. The two problems there are that "freeware" isn't a personality, and that most of what's in SFW actually doesn't in any way duplicate functionality found elsewhere on the system; it's actually a part of the default OpenSolaris personality. The stuff that's being delivered to /usr/sfw belongs in /usr; it uses commonly accepted prefixes to distinguish programs where necessary, so that both are available without a path change simply by using the standard names. Adding /usr/gnu allows a user to select the GNU personality wholesale, or to use a specific program using the prefixed name. It also serves as a logical place to add some of the utilities you've mentioned, such as autoconf, even though it might be thought undesirable for autoconf to be placed in /usr/bin, and unexpected for it to be prefixed with g since the GNU flavour of this tool is the only one in existence. > Some of the stuff is definitely not in Solaris, some is but exactly > because of the differences (like the g suffix) we are unable to use it. > The Companion is probably not any more architecturally reviewed than > the JDS CBE. Correct; the Companion is entirely unreviewed. It's a separate product and not a part of Solaris; each release is a Major release. That's not to say that other distributions mightn't wish to incorporate it, with the understanding that its contents come with no architectural guarantees. It would be useful to define the distinction between broken source and missing or poorly-presented OpenSolaris features. For example, suppose there is a Free Software component called foo. foo's build instrstructure requires GNU diff, and it always assumes that /usr/bin/diff is GNU diff. Is its failure to build on Solaris a bug in foo (for making an unportable assumption about the build system) or in OpenSolaris (for not being the One True System)? What if foo's build honours PATH but still assumes that any 'diff' it finds is GNU diff without looking for gdiff first? Or is it simply a bug that foo relies on GNU diff? -- Keith M Wesolowski "Sir, we're surrounded!" Solaris Kernel Team "Excellent; we can attack in any direction!"
