Stephen Hahn wrote: > Since this topic arose during a discussion about developer readiness > of opensolaris, and got reasonably well characterized, and appears to > be gating on other improvements, I thought we should discuss further > with a draft in hand. > > Comments welcomed. > > - Stephen
> Stephen Hahn (sch at sun.com) [and anyone else who dares to be forever > blamed for this] You may add my name. When this arose originally the idea was that /usr/gnu would be used only for those command, libs, etc, that had name conflicts with other versions found in /usr/bin, /usr/xpg*/bin, etc. To include other commands here that are not yet deemed sufficiently stable for inclusion in the default path seems to resurrect the idea that interface stability can be inferred from the path used to find that interface, something I tried to discredit in PSARC/2005/185, "Enabling serendipitous discovery". As I wrote in that case regarding the sequestering of open source software in /usr/sfw: > Today, Solaris ships many useful components under /usr/sfw. These > components are classified as External; the Interface Taxonomy definition > of External Interfaces are: > > These interfaces are controlled by a body outside of Sun, but > unlike Standard, it can not be asserted that an incompatible > change to the interface would be exceedingly rare. In some > cases it may not even be possible to clearly identify the > controlling body. This classification is typically used > for community software, freeware, open source and the like. > > In PSARC/2000/487, PSARC required that the user "perform > a simple but explicit act" to gain access to any interfaces > with an External classification. The rationale for this requirement > was to insure that the user did not inadvertently depend on > a software component that did not meet the ``Sun Application Binary > Guarantee''. Thus, any External component could not be found in the > default search path. > > Since this policy was created, the situation has changed significantly. > Rather than simply providing alternate implementations of existing > Solaris tools, the components with External stability classifications > now provide key critical functionality, including web browsers, > entire desktops, etc; Solaris would not appear functional without > these components. > > As a result this requirement is now perceived as a hindrance to Solaris > users. With a large number of users having Linux experience prior > to their first experience with Solaris, our delineation of interface > stability levels using directories goes largely unnoticed, while the > lack of the usual software facilities for the newly configured user > is remarked upon. In addition, more and more users depend on the > functionality we ship in /usr/sfw, including our default web browser, > bundled compilers, etc. This forces almost all sophisticated users > to alter their shell search paths, defeating any "warning" provided > by the location of the command. > > Given that our man pages for all commands and libraries clearly > specify the Interface Stability level (another SAC requirement), > forcing users to add additional directories to their path seems to add > little to the safely of the user/developer, while needlessly > frustrating the casual or exploratory user. It has also led to torturous > ARC discussions regarding access to required functionality that has > External interface stability, and has led to such absurdities as having a > menu on the default desktop to launch Mozilla, but having Mozilla not > be found when invoked from a shell with the default path in order to > protect the user. I would like the development tools, etc, needed to build open source software to be found on the default path as much as possible; this would argues for inclusion of uniquely named commands in /usr/bin. Should it become necessary once for software developers to add /usr/gnu/bin to the end of their path to pick up needed commands such as libtool or automake, all further value of the separate path is lost as additional "unstable" commands will be found automatically. I think that if the command is important enough to be part of Solaris, and is uniquely named, we should install it in /usr/bin where it may be readily found. - Bart -- Bart Smaalders Solaris Kernel Performance barts at cyber.eng.sun.com http://blogs.sun.com/barts
