[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.
- Re: [gpsd-dev] scons quirks, (continued)
- Re: [gpsd-dev] scons quirks, Eric S. Raymond, 2013/11/18
- Re: [gpsd-dev] scons quirks, Hal Murray, 2013/11/18
- Re: [gpsd-dev] scons quirks, Eric S. Raymond, 2013/11/19
- Re: [gpsd-dev] scons quirks, Mike Frysinger, 2013/11/21
- Re: [gpsd-dev] scons quirks, Eric S. Raymond, 2013/11/22
- Re: [gpsd-dev] scons quirks, Mike Frysinger, 2013/11/27
- Re: [gpsd-dev] scons quirks, Eric S. Raymond, 2013/11/27
- Re: [gpsd-dev] scons quirks, Mike Frysinger, 2013/11/27
- Re: [gpsd-dev] scons quirks, Eric S. Raymond, 2013/11/30
- Re: [gpsd-dev] scons quirks, Miroslav Lichvar, 2013/11/27
- Re: [gpsd-dev] scons quirks,
Hal Murray <=
- Re: [gpsd-dev] scons quirks, Gary E. Miller, 2013/11/27
- Re: [gpsd-dev] scons quirks, Hal Murray, 2013/11/27
- Re: [gpsd-dev] scons quirks, Gary E. Miller, 2013/11/27
- Re: [gpsd-dev] scons quirks, Eric S. Raymond, 2013/11/28
- Re: [gpsd-dev] scons quirks, Eric S. Raymond, 2013/11/30
- Re: [gpsd-dev] scons quirks, Eric S. Raymond, 2013/11/28
- Re: [gpsd-dev] scons quirks, Hal Murray, 2013/11/29
- Re: [gpsd-dev] scons quirks, Hal Murray, 2013/11/29
- Re: [gpsd-dev] scons quirks, Greg Troxel, 2013/11/29
- Re: [gpsd-dev] scons quirks, Miroslav Lichvar, 2013/11/29