[Fedora-packaging] Updating our rpath guidelines?

[Toshio Kuratomi]

On Mon, Nov 08, 2010 at 12:57:21PM +0000, Michel Alexandre Salim wrote:
> On Sun, 07 Nov 2010 12:45:07 -0500, Orcan Ogetbil wrote:
> 
> > On Sat, Nov 6, 2010 at 10:03 PM, Michel Alexandre Salim wrote:
> >> Hi all,
> >>
> >> Several months ago, Mamoru Tasaka suggested a less intrusive way of
> >> patching a source package's bundled libtool so that /usr/lib64 does not
> >> end up in the installed binaries.
> >>
> >>       So actually for most cases, the case that rpath /usr/lib64 is
> >>       added (only for 64 bits arch) can be avoided by
> >> 
> ------------------------------------------------------------------------
> >> sed -i.libdir_syssearch -e \
> >>   '/sys_lib_dlsearch_path_spec/s|/usr/lib |/usr/lib /usr/lib64 /lib
> >>   /lib64 |' \ configure
> >> 
> ------------------------------------------------------------------------
> >>       i.e. just add the needed paths to sys_lib_dlsearch_path_spec
> >>       in configure (note that libtool in the build directory is
> >>       generated by configure) before calling %configure. - You can
> >>       alternatively do "autoreconf -fi", however calling autotools
> >>         is not recommended unless unavoidable.
> >> ----------
> >>
> >> I have several packages using the old-style DIE_RPATH_DIE
> >> (http://fedoraproject.org/wiki/Packaging/Guidelines#Beware_of_Rpath)
> >> sed hack, and while they've been working out fine so far, I just
> >> noticed when updating Vala today that this rather invasive change is
> >> responsible for Vala's test suite not to run: since the Vala libraries
> >> have not been installed on the system when the tests were run, Rpath is
> >> actually necessary to run the tests!
> >>
> >>
> > Did you try LD_PRELOAD or LD_LIBRARY_PATH? Something like
> > 
> > %check
> > cd tests/
> > LD_LIBRARY_PATH=../src/.libs ./run_tests
> > 
> That'd probably work, yes, but given that one needs to stop /usr/lib64 
> from appearing in the rpath of the installed binaries anyway, surely one
> clean fix is better than two hackish ones?
> 
> If we update the guideline, then upstream's build scripts should *just 
> work* (unless it's the Mono stack where /lib is hardcoded all over the 
> place...)
> 
So the rpath is pointing to the temporary location where the library was
built?  If so, those rpaths don't belong either (as they expose you to
potential security problems if someone puts a library into that directory on
a running production system).

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/packaging/attachments/20101108/d3147de0/attachment.bin