> On Tue, Jan 30, 2007 at 05:29:16PM -0800, Richard L. > Hamilton wrote: > > Ok, fine. Then throw whatever non-conflicting > commands you like > > into /usr/bin and call it serendipitous discovery. > > > > But also create a /usr/sun or whatever and populate > it with > > symlinks only to commands that don't come from > external open source (or > > have historically diverged significantly from > them); > > Except that historically /usr/bin isn't all of a > single provenance. So > you want to take a snapshot of /usr/bin as it stands > today and "copy" it > to some other location where we'll only ever add... > what? nothing? > hings developed at Sun? or in the OpenSolaris > community but not of some > other FOSS or even proprietary provenance?
Past a snapshot at the present time (give or take some things that arguably shouldn't have gone into /usr/bin in the first place, like the GNOME stuff), only things added specifically via Sun or OpenSolaris; that way, they would not simply be out-of-sync snapshots of FOSS from elsewhere that sites might wish to use their own builds of, whether to be more nearly current or to standardize on specific versions enterprise-wide. Typically, I'd see those as either not conflicting with /usr/gnu (i.e. something that implements Solaris-specific functionality, like zonename or svcs) or perhaps a command updated for standards compliance if the version in /usr/gnu wasn't compliant, although in the latter case, it would be better to try first to push compliance mods out to the external source, so as to have a single command that had the combined functionality. Of course, one could think of examples where it might want to argue either way what should go in there. For instance, I'd say that if and when ksh becomes oksh and the new ksh is the integrated ksh93, I'd say it would be ok to reflect that in /usr/sun, as simply an update of an existing item (and incidentally, not inconsistent with historical lineage, since ksh88 was in SVR4.0, I think; while ksh93 is probably already in most more recent SVR4 derivatives other than Solaris). Bottom line is principle of least surprise for those who wish traditional Solaris functionality supplemented by directories of commands of their own choosing. Although admittedly, that's not altogether easy to expand into a set of rules that would cover every situation. Still, I think some reasonable guidance ought to be possible for how it should be maintained. And if there were something that might conflict, but then again might not be in some site's directory, they could always go with PATH=/usr/sun:/site/path:/usr/bin to pick up the Solaris-specific stuff first, followed by their preferred versions, with anything left in /usr/bin that those might not have as a last resort. This message posted from opensolaris.org
