[csw-maintainers] RPATH/ISALIST (zlib package in /testing)

[Roger Håkansson]

James Lee wrote:
> 
> It expands to the isalist.  It tries all in order but if it's a 32 bit
> prog there is never a valid match in the 64s, then it runs through the
> 32s until the match, or not in the case of this first non CSW lib:
> 

And your solution to that "problem" is?
Add all 32bit paths to RPATH/RUNPATH when building a 32bit app/lib, 
instead of just $ISALIST?

> Once built a package doesn't know how it was built so if it works
> use it.

Parse error...

> LD_OPTIONS overrides all so is powerful.  Like all powerful weapons
> use with caution.
> 

My point was that LD_OPTIONS is used by default when building using gar.
And those broken RPATH/RUNPATHs was due to a bug in gar, not what the 
maintainer might have set (or not set).

>> To reiterate my question:
>> Is there any actual harm (disregarding the fact that the link loader
>> might have to traverse /opt/csw/lib/$ISALIST:/opt/csw/lib without
>> finding any match) having RPATH/RUNPATH set?
> 
> No, well it's actual but trivial.
> 
> 
>> If not, it is only when a package doesn't use any libs at all from
>> /opt/csw/lib, when RPATH/RUNPATH should be changed from the default.
> 
> Correct, as is the case with zlib.

I'm not thinking of just zlib, I'm speaking in a more general term plus 
"should" should have been "could".

Since we have established that its not harmful to have RPATH set even 
when its not used, I can see more problem (as in more work for the 
maintainer in the future) with actively unsetting LD_OPTIONS than not.


>> If package A is linked to a lib i package B (both CSW packages) and A i
>> packaged with RPATH/RUNPATH set to only /opt/csw/lib, any future
>> releases of B which contain optimized libraries won't be used until A is
>> repackaged with RPATH/RUNPATH set to /opt/csw/lib/$ISALIST:/opt/csw/lib
> 
> Correct.  Add $ISALIST in, unless you know it won't be needed.

And my point is that you can't know if its going to be needed or not at 
the time of package (unless you are both maintaner of A and B and know 
that you won't package optimized version of B).

>> And if there is a longer dependency list (A->B->C-D where D is the one
>> with optimized libs) it creates much more work for the maintainer of A
>> (he must check every lib in the dependency path to see if there are any
>> optimized libs).
> 
> D is governed by the RPATH of C.  C by B.

You're correct (at least if C and B are linked with required libraries, 
reference to my post the other week regarding gpdf and libnet), my 
memory was wrong.