gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] scons quirks


From: Hal Murray
Subject: Re: [gpsd-dev] scons quirks
Date: Wed, 27 Nov 2013 11:13:24 -0800

address@hidden said:
> It would be nice if packagers didn't have to use chrpath at all. Now I need
> it to remove RPATH from all gpsd binaries and libraries to comply with our
> policy as they are set in the installation to /usr/lib or /usr/lib64.

My 2 cents, and I could be totally wrong...

There are 2 problems tangled up with RPATH.

One is testing the new code before it gets installed.  The other is that the 
default installation goes to /usr/local/xxx rather than /usr/xxx.

If you are going to install the libraries in /usr/lib/, then the executables 
don't need any RPATH to find them.  I think scons with chrpath=no should 
handle that case.  A line or 2 of code in the right place could leave out the 
RPATHs totally rather than setting them to /usr/lib

That leaves the problem of how to test things.  I think the LD_LIBRARY_PATH 
environment variable does the same thing.  If so scons check could use that.  
That doesn't cover manual testing of things like gpsmon.  I'm not enough of a 
shell wizard to work out a good proposal, but I'll bet somebody could come up 
with something like a set of aliases that would handle that problem and an 
easy way to set them up.

A secondary approach for testing is just to install the new code and test it 
post install.  That seems quite reasonable in the context of packaging where 
you expect it to work as compared to development where you might like to 
leave the installed code in a known-good state.  (I'm assuming you are doing 
the packaging on a personal system where you can test things rather than a 
public server where you might inconvenience other people.)





-- 
These are my opinions.  I hate spam.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]