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 <[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
--
Jeff Squyres
Cisco Systems
_______________________________________________
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
