Re: Re: RPM source files should be in CVS (was Re: [GENERAL] psql -l)

On Friday 20 July 2001 19:56, Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > How is this search path defined?  Blindly using libdir is not ok --

> Why not?

During RPM build, libdir will point to /usr/lib.  This is OK and appropriate 
for the generally-loadable shared libs.  HOWEVER, the shared objects that are 
affected by this function handler load search path will not be located in 
/usr/lib -- as they are not generally loadable shared libraries, but 
PostgreSQL-only shared libraries.  Thus, /usr/lib/pgsql is the home for 
those, and, in an RPM installation, should be the head of any shared object 
load path searched by the PostgreSQL dynaloader.

/usr/lib -> system dynaloader default for non-essentials (/lib of course for 
libs essential for boot)
/usr/lib/pgsql -> PostgreSQL dynaloader default (ideally, on an FHS-compliant 
installation).

> The search path is defined in postgresql.conf (and I see Peter forgot
> to add an example to the postgresql.conf.sample file), but the default
> is the backend-compile-time $libdir.  Offhand I don't see what's wrong
> with it.

I can patch postgresql.conf.sample easily enough -- but, if I'm trying to get 
away from RPM-specific patches.... :-) I have heretofore not modified the 
default postgresql.conf in anyway -- no tuning, no tcpip_socket setting (for 
which I get some grief, as people running  RPMs of 7.0.x are used to -i being 
on by default), no nothing.

Not knowing alot about autoconf, I hesitate to suggest or ask the following, 
but I will anyway -- is it possible to define an optional 
'so-search-path-default' switch for the backend's dynaloader?  This has 
nothing to do with the OS dynaloader path, for which there is a well-defined 
config file on most OS's -- just the backend's function handler dynaloader.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11