James Carlson wrote: > 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. > Hummm, PSARC is lax about this, but other ARCs are more concerned about the name of the packages - SUNWfoobar - than PSARC. Sometimes we do show interest.
I don't think SAC says anything about what Meta-Cluster the packages end up in. I would like to think it is a Marketing/Management concern, but I have a bad feeling that this isn't anybody's concern, and this just happens. If there was control of the Meta-Clusters, one check-box should be "none". So yes, I agree with your assesment of FileBench. I'm just pointing out a general "hole" in our broader processes which are being stressed by the influx of FOSS. > 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? > No. I think this specific case needs to resolve the "to bin or not to bin" question, independently of an repository concerns. >> 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. > ;-} > :-) - jek3
