[openib-general] Open MPI rpmbuild fails in OFED-1.2
Scott Weitzenkamp (sweitzen)
sweitzen at cisco.com
Wed Feb 14 10:44:14 PST 2007
Tziporet and Doug, we can discuss this at the OFED conf call on Feb 26,
I suggest we try to improve this area.
Scott Weitzenkamp
SQA and Release Manager
Server Virtualization Business Unit
Cisco Systems
> -----Original Message-----
> From: openib-general-bounces at openib.org
> [mailto:openib-general-bounces at openib.org] On Behalf Of Doug Ledford
> Sent: Wednesday, February 14, 2007 10:36 AM
> To: Jeff Squyres (jsquyres)
> Cc: openfabrics-ewg at openib.org; 'Openib-General at Openib.Org'
> Subject: Re: [openib-general] Open MPI rpmbuild fails in OFED-1.2
>
> On Fri, 2007-02-09 at 13:38 -0500, Jeff Squyres wrote:
> > New SRPM on server that munges the %build section into the
> %install
> > section.
> >
> > Yuck. :-)
>
> Worse than yuck, it's wrong. Your SuSE %build section bug is a result
> of trying to build against something that isn't installed yet but is
> required for the build. You guys chose to split things up
> into modules,
> and that's fine and the way things should be, but that means
> you need to
> install required packages along the way if you want to build against
> them, not try to build against binaries in temporary
> directories. Apart
> from that though, I can assure you that on RHEL and FC, the %build
> section is a requirement if you want valid -debuginfo packages.
>
> I've brought it up at the last two conferences I attented,
> and I usually
> get a brick wall when I do, but the OFED packaging process is
> broken by
> design. As Shaun brought up, one of the benefits of proper RPM
> packaging is reliable, reproducible builds, not to mention the whole
> issue of debugging with gdb is nigh impossible without valid debuginfo
> rpms; all of which are vital to supportability.
>
> I'm looking through the alpha1 tarball right now, I'll comment on it
> later under separate email. But, first glance is that I'll be ripping
> everything out and making it sane again.
>
> Which brings up another point that I've mentioned before but
> nothing has
> happened on: as long as you guys keep making your distribution use an
> installation hierarchy that violates the rules for distributions
> shipping code, places like Novell or Red Hat have one of two choices:
> violate the Linux File Hierarchy Standard in our
> distributions or use a
> different hierarchy than you do. Obviously, we aren't going
> to fore go
> LFHS compliance of our entire product for just this, so we use a
> different hierarchy than you. In the end, this can end up causing
> confusion for customers, as well as inconsistency between what Red Hat
> or Novell or you guys choose to use as the file placement. Something
> needs to be done to standardize installation directories in an
> acceptable place IMO (/usr/local is verboten for a
> distribution to use,
> and theoretically that should include you guys since you are a
> distribution source, the only real reason people are
> compiling your code
> locally is that you don't provide binary RPMs or because they want a
> custom compiler instead of gcc, not because they are trying out new
> software they don't necessarily intend to keep/use or which is new
> enough that no one has formally packaged it up, which is what
> /usr/local
> is for).
>
> >
> > On Feb 7, 2007, at 11:42 AM, Vladimir Sokolovsky wrote:
> >
> > > Hi Jeff,
> > > Please remove %build macro from the RPM spec file.
> > > On SuSE distros it removes RPM_BUILD_ROOT.
> > >
> > > Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.23343
> > > + umask 022
> > > + cd /var/tmp/OFEDRPM/BUILD
> > > + /bin/rm -rf /var/tmp/OFED
> > > ++ dirname /var/tmp/OFED
> > > + /bin/mkdir -p /var/tmp
> > > + /bin/mkdir /var/tmp/OFED
> > > + cd openmpi-1.2b4ofedr13470
> > > + fortify_source=1
> > > + test '' '!=' ''
> > > ...
> > >
> > > --
> > > Vladimir Sokolovsky <vlad at dev.mellanox.co.il>
> > > Mellanox Technologies Ltd.
> >
> >
> --
> Doug Ledford <dledford at redhat.com>
> GPG KeyID: CFBFF194
> http://people.redhat.com/dledford
>
> Infiniband specific RPMs available at
> http://people.redhat.com/dledford/Infiniband
>
More information about the general
mailing list