Re: Relocatable installs - Mailing list pgsql-hackers

Bruce Momjian <pgman@candle.pha.pa.us> writes:

> Greg Stark wrote:
> > Jan Wieck <JanWieck@Yahoo.com> writes:
> > 
> > > You know how much trouble that causes? The existance of LD_LIBRARY_PATH in your
> > > environment disables setuid() for security reasons on some platforms. So one
> > > would have to wrap every PG related program into equally named shell scripts or
> > > aliases to just set it for the program call alone.
> > 
> > Why would any pg tools need to be setuid?
> 
> I assume he is saying that you would have problems having that set all
> the time.  You would need to set it only before running pg binaries,
> which is a pain.

I've never heard of any system where that's the case. Normally the loader
simply ignores the LD_LIBRARY_PATH LD_PRELOAD etc. for setuid/setgid programs.

I feel weird here giving ammunition that LD_LIBRARY_PATH is happy while
simultaneously arguing it shouldn't be used though.

> > > Relocatable installation means static linking of our tools against our own
> > > libs. This does not mean static linking entirely, but at least static linking
> > > against libpq.a.
> > 
> > The normal approach is to use rpath for relocatable installs. 
> > That's what it's there for. 
> > Static linking would work too but it's overkill.
> 
> The point is that we want someone to be able to do an install, and then
> be able to move the pgsql directory.  When we use rpath, the installed
> binary has a hardcoded path for the libraries.

You do? That doesn't generally work. To do that you have to break all the unix
conventions about config files in /etc, platform independent files in /share,
modified data in /var, etc. I know postgres currently violates these
conventions, but most unix programs don't so anyone who has such an
expectation is in for a lot of surprises. 

And long term I expect postgres to head in the direction of complying with
these conventions so distributions can stop kludging around the violations
with symlinks and wrapper scripts. Writing in more assumptions about the
non-standard installation will only create more pain down the road.

Generally I've only heard "relocatable" to refer to RPM packages that could be
installed to a non-standard prefix. For that you need an install script that
knows what magic has to be done. Not a directory that can be moved around
willy-nilly *after* installation.

> > But please don't use rpath for installs to standard paths like
> > /usr/{local,}/lib. That way lies madness.
> 
> We don't.  By default it is /usr/local/pgsql/lib, which isn't standard. 

Well that sucks, but that's for another day :)

As long as it is in a non-standard location then rpath really ought to be set.
Requiring every user of a program to set environment variables before it works
properly is lame. It engenders the kde/qt/oracle headaches of having to adjust
LD_LIBRARY_PATH for every user every time you install or update a package.

Of course rpath is evil, which is precisely why packages ought not be
installed in such non-standard locations...

-- 
greg