Filebench [PSARC/2007/448 FastTrack timeout 08/16/2007]

[Joseph Kowalski]

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