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 <[EMAIL PROTECTED]>
> > Mellanox Technologies Ltd.
>
>
--
Doug Ledford <[EMAIL PROTECTED]>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
signature.asc
Description: This is a digitally signed message part
_______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
