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

[Michael S. Tsirkin]

> 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