On 9/1/05, Michael Jennings <[EMAIL PROTECTED]> wrote: > On Thursday, 01 September 2005, at 08:28:17 (+0900), > Carsten Haitzler wrote: > > > > well, as you can see, some distro's like to clamp down on RPATH's (for > > > whatever reasons/policies/boredom) > > > > > > so Eterm is going to be changed, it'd just be nice if we could do it with > > > a > > > simple ./configure option rather than patching it ourselves ;) > > > -mike > > > > but what is the REASON for this rpath removal policy? i'm curious to know > > why! > > i'm wondering how it causes problems or breaks things or such... ? i'd > > really > > like to know! :) > > Exactly! Couldn't have said it better myself. >
This is provided from Ville Skyttä author of the fedora-rpmdevtools--- But the author of the check-rpath sript is Enrico Scholz <[EMAIL PROTECTED]>. Maybe we should ask him too. ---------------------------------------------------------------------------------------------------------------------- >From Ville: Here's something: http://people.debian.org/~che/personal/rpath-considered-harmful http://wiki.debian.net/index.cgi?RpathIssue Mind you, the case of "standard library paths" in RPATH is the least severe "error" detected by check-rpaths. What's more useful in it in general are the checks for RPATHS that might cause security problems (empty RPATHs, buildroot remainders etc). As far as I can tell, standard paths like /usr/lib in RPATH are mainly of academic interest and the cases where they'd bite are very rare in practice. But if they don't add any value whatsoever on our platform (and can at least theoretically be harmful), why not just get rid of them? For more information, see the contents of the check-rpaths and check-rpaths-worker scripts, including the information about the scripts' author's email address; I'm sure Enrico would be happy to provide more insightful information if needed. -- With kind regards, Didier. ------------ Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe Didier F.B Casse PhD candidate, Singapore Synchrotron Light Source (SSLS) National University of Singapore. ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
