[ewg] Fwd: [ofa-general] OFED 1.2 Feb-26 meeting summary

Jeff Squyres jsquyres at cisco.com
Sun Mar 18 11:02:22 PDT 2007


We can do it better by one of the two methods that has been proposed  
many times:

1. Use chroot to build everything.
2. Install while we build.

Either of these would eliminate a bunch of ugliness from the OMPI  
portion of the OFED installer, and also eliminate the need for a at  
least some portion of ugliness that is in the OMPI specfile.


On Mar 18, 2007, at 7:48 AM, Michael S. Tsirkin wrote:

>> Quoting Jeff Squyres <jsquyres at cisco.com>:
>> Subject: Re: [ewg] Fwd: [ofa-general] OFED 1.2 Feb-26 meeting summary
>>
>> It seems odd to me that you [repeatedly] brush off several members of
>> the community that are saying that it's *not* working smoothly  
>> enough.
>
> I actually agree there are problems, I just don't necessarily agree  
> with the
> solution of focusing on RHEL/SLES exclusively. And I do not like  
> writing long
> missives where a short sentence will do - sorry if this sounds  
> dismissive.
>
>> 1. We're doing things in the installer that are very much *not* what
>> any Linux distro wants us to do (e.g., munge %build into %install).
>
> I'm not sure why do we do this, actually.
>
>> 2. RHEL and SLES -- two of our Big community targets -- are replacing
>> all of our installer work with their own.
>
> This is probably for the best. I expect they can also throw away a ton
> of backports and whatnot.
>
>> 3. The MPI packages all have to do weird (read: non-standard and
>> potentially hazardous) things to get installed properly.
>
> I think the tricks they do are quite broken, too.
> No idea how to do it better though.
>
>> This is not the first time that Doug and I have tried to say "what
>> we're doing is wrong!"
>>
>> More below.
>>
>>
>>
>> On Mar 17, 2007, at 6:13 PM, Michael S. Tsirkin wrote:
>>
>>>>> 2. *NOT AN MPI ISSUE*: how the RPMs are built is Bad(tm).  Not
>>>>> deleting the buildroot is Bad; munging %build into %install is
>>>>> Bad; ...etc.  This needs to change.  4 choices jump to mind:
>>>>>
>>>>>    a. Keep the same scheme.  Ick.
>>>>>    b. Install while we build (i.e., the normal way to build a pile
>>>>>       of interdependent RPMs)
>>>>>    c. Use chroot (Red Hat does this in their internal setup,  
>>>>> for example)
>>>>>    d. Only distribute binary RPMs for supported platforms;
>>>>>       source is
>>>>>       available for those who want it.
>>>>
>>>> d. is the normal route for anyone wanting to provide a known  
>>>> working
>>>> environment.  Building locally is fraught with perils related to
>>>> custom compilers, custom core libraries, and other things that  
>>>> the EWG can't
>>>> control and can't realistically support.
>>>
>>> I don't think d is realistic simply because OFED is not redhat, it
>>> needs to be distribution agnostic.
>>
>> But OFED is *not* distribution agnostic.  We have a specific,
>> documented set of distributions that we support. Having the source
>> code available is great, of course.  But Cisco, for example, supports
>> only a specific set of distros/versions and we distribute binaries
>> for them.  I believe that others may be doing the same...?
>
> Is there something that prevents you from doing this?
> Can't you build with prefix /usr?
>
>>> In our experience people *want* to use custom compilers,
>>> custom core libraries etc.
>>
>> Do you have customers who build the OFA code base with non-GNU
>> compilers?  Right now, the OFED installer only lets you choose none-
>> GNU compilers for the MPI installations -- not the OFA code base
>> itself.  If this is your strongest point, then refer to what I said
>> above:
>>
>> a) it's the MPI implementations that are complaining that what we are
>> doing is Bad
>> b) it's the MPI implementations that have to do weird/non-standard/
>> potentially hazardous things to get installed properly
>
> I know I am very interested in e.g. cross-compiling the OFED core.
> I'm not too involved with MPI per se.
>
> -- 
> MST


-- 
Jeff Squyres
Cisco Systems




More information about the general mailing list