> Quoting Jeff Squyres <[EMAIL PROTECTED]>: > 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 _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
