Joseph Kowalski writes: > Not to pick on "Filebench", but it seems like we are throwing > everything, including > the kitchen sink, into Solaris. If we had a distribution repository > (like Ubuntu/Debian), > we would just make it available in the repository, and be done with it.
Even if we had such a repository, it would not change this case very much. We'd need some place to install that software on the system when fetched from the repository. There are two distinct variables here, and I don't think we should tie them together. The two are the installed location of the software on the system (when the package is opened), and the groupings of packages into logical units for a repository. This case specifies the former, but doesn't specify the latter, and I'm not so sure that the case would necessarily be different even if the latter part were rewhacked radically. Perhaps your argument should be that this belongs in /usr/bin or /usr/sbin instead. I'm unsure that it does. If you choose to install a benchmarking tool from the repository, do you want it showing up in every user's path? If so, why? > Can we do something (in OpenSolaris) to track which new items are > clearly items > which would not be included in "standard" bundles? Classifying this as > Uncommitted > goes a long way to make this feasible. Should I be concerned about more > than that? > Maybe this is only a *real* concern for something "Committed", but > "repository > appropriate"? I think the right way to go about doing this would be to ask about the intended Cluster and Metacluster (if any) for the SUNWfilebench package. Go ahead and get as detailed as you want on that question. ;-} -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
