[openib-general] Open MPI rpmbuild fails in OFED-1.2

Jeff Squyres jsquyres at cisco.com
Thu Feb 8 05:35:13 PST 2007


On Feb 7, 2007, at 2:49 PM, Michael S. Tsirkin wrote:

>> My $0.02: This is another in a growing list of issues reflecting the
>> whole "build everything in DESTDIR" is a problematic approach.
>
> I don't know much about RPM, and I am not exactly sure why are
> our source RPMs so complicated.

It's a combination of two things:

1) similar to what you said below, we have lots of software packages  
that are all dependent upon each other
--> this leads to a conglomeration of rpath's and shared library  
dependencies that are incorrect

2) we're trying to *use* the software when it is installed in the  
DESTDIR
--> this means that you have to put special-case in the software so  
that they look for support files in both the DESTDIR *and* the final  
installation directory

One way to think about what we're doing is making a disk image and  
then snapshotting RPMs from that disk image.  That's a natural  
candidate for chroot.

> However, with the plan configure/make we are able to
> build all openfabrics components within build directory,
> without any chroot tricks.
>
> So let's not give up yet, IMO it is very nice to be able to build in
> standard environment, without being root.

Yes, it's nice from the user perspective.  But it's fairly annoying  
from the developer point of view because you have to add all these  
special cases.

> Note that what is biting us here is mostly the large number of  
> modules:
> simple single-module packages don't have this problem - and this
> is really a design decision we took.

Understood.  I guess I'm asking whether all these special cases  
required to support the DESTDIR approach are a) worth it, b) going to  
take more time to get right (which end up being somewhat fragile)  
than to use a chroot/image-based approach.

Again, just my $0.02, and I might get shouted down.  But I thought  
I'd at least ask...  :-)

-- 
Jeff Squyres
Server Virtualization Business Unit
Cisco Systems





More information about the general mailing list