Postgresql8.4 install breaks Evolution on Ubuntu 9.10

A quick-fix solution is deleting the file
'/opt/PostgreSQL/8.4/lib/libxml2.so.2'.

On 11/28/2009 04:23 PM, Leonardo Camargo wrote:

Hi all,
I'm wondering if someone here know how to go about fixing this problem
that apparently affects everyone who manually install Postgresql8.4 on
Ubuntu Karmic(9.10).

Postgres installation seems to mess with something that renders other
applications unable to function. For instance my problem is with
Evolution Mail. This is the output I started getting after installing
postgres:

evolution: /opt/PostgreSQL/8.4/lib/libxml2.so.2: no version
information available (required by evolution)
evolution: /opt/PostgreSQL/8.4/lib/libxml2.so.2: no version
information available (required by
/usr/lib/evolution/2.28/libemiscwidgets.so.0)
evolution: /opt/PostgreSQL/8.4/lib/libxml2.so.2: no version
information available (required by /usr/lib/libgdata-1.2.so.1)
evolution: /opt/PostgreSQL/8.4/lib/libxml2.so.2: no version
information available (required by /usr/lib/libgdata-1.2.so.1)
evolution: /opt/PostgreSQL/8.4/lib/libxml2.so.2: no version
information available (required by /usr/lib/evolution/2.28/libetable.so.0)
evolution: /opt/PostgreSQL/8.4/lib/libxml2.so.2: no version
information available (required by /usr/lib/evolution/2.28/libeutil.so.0)
evolution: /opt/PostgreSQL/8.4/lib/libxml2.so.2: no version
information available (required by /usr/lib/evolution/2.28/libeutil.so.0)
evolution: /opt/PostgreSQL/8.4/lib/libxml2.so.2: no version
information available (required by /usr/lib/libebook-1.2.so.9)
evolution: /opt/PostgreSQL/8.4/lib/libxml2.so.2: no version
information available (required by /usr/lib/libedataserver-1.2.so.11)
evolution: /opt/PostgreSQL/8.4/lib/libxml2.so.2: no version
information available (required by /usr/lib/libsoup-2.4.so.1)
evolution: /opt/PostgreSQL/8.4/lib/libxml2.so.2: no version
information available (required by /usr/lib/libgnomevfs-2.so.0)
evolution: /opt/PostgreSQL/8.4/lib/libxml2.so.2: no version
information available (required by /usr/lib/libgnomevfs-2.so.0)
evolution: /opt/PostgreSQL/8.4/lib/libxml2.so.2: no version
information available (required by /usr/lib/libgnomevfs-2.so.0)
evolution: relocation error: /usr/lib/evolution/2.28/libeutil.so.0:
symbol xmlFirstElementChild, version LIBXML2_2.7.3 not defined in file
libxml2.so.2 with link time reference

I can't be sure(no logs) but VMWare Workstation seems to have been
affected here too, can't get it to work anymore.

Other people having the same problem:
http://ubuntuforums.org/showthread.php?t=1307864
https://bugs.launchpad.net/ubuntu/+bug/461105

Best regards,
Leonardo C.

--
Regards,
Sachin Srivastava
EnterpriseDB <http://www.enterprisedb.com&gt;, the Enterprise Postgres
<http://www.enterprisedb.com&gt; company.

On Sat, Nov 28, 2009 at 11:53, Leonardo Camargo
<camargoleonardo@gmail.com> wrote:

Hi all,
I'm wondering if someone here know how to go about fixing this problem that
apparently affects everyone who manually install Postgresql8.4 on Ubuntu
Karmic(9.10).

Postgres installation seems to mess with something that renders other
applications unable to function. For instance my problem is with Evolution
Mail. This is the output I started getting after installing postgres:

evolution: /opt/PostgreSQL/8.4/lib/libxml2.so.2: no version information
available (required by evolution)
evolution: /opt/PostgreSQL/8.4/lib/libxml2.so.2: no version information
available (required by /usr/lib/evolution/2.28/libemiscwidgets.so.0)
evolution: /opt/PostgreSQL/8.4/lib/libxml2.so.2: no version information
available (required by /usr/lib/libgdata-1.2.so.1)
evolution: /opt/PostgreSQL/8.4/lib/libxml2.so.2: no version information
available (required by /usr/lib/libgdata-1.2.so.1)
evolution: /opt/PostgreSQL/8.4/lib/libxml2.so.2: no version information
available (required by /usr/lib/evolution/2.28/libetable.so.0)
evolution: /opt/PostgreSQL/8.4/lib/libxml2.so.2: no version information
available (required by /usr/lib/evolution/2.28/libeutil.so.0)
evolution: /opt/PostgreSQL/8.4/lib/libxml2.so.2: no version information
available (required by /usr/lib/evolution/2.28/libeutil.so.0)
evolution: /opt/PostgreSQL/8.4/lib/libxml2.so.2: no version information
available (required by /usr/lib/libebook-1.2.so.9)
evolution: /opt/PostgreSQL/8.4/lib/libxml2.so.2: no version information
available (required by /usr/lib/libedataserver-1.2.so.11)
evolution: /opt/PostgreSQL/8.4/lib/libxml2.so.2: no version information
available (required by /usr/lib/libsoup-2.4.so.1)
evolution: /opt/PostgreSQL/8.4/lib/libxml2.so.2: no version information
available (required by /usr/lib/libgnomevfs-2.so.0)
evolution: /opt/PostgreSQL/8.4/lib/libxml2.so.2: no version information
available (required by /usr/lib/libgnomevfs-2.so.0)
evolution: /opt/PostgreSQL/8.4/lib/libxml2.so.2: no version information
available (required by /usr/lib/libgnomevfs-2.so.0)
evolution: relocation error: /usr/lib/evolution/2.28/libeutil.so.0: symbol
xmlFirstElementChild, version LIBXML2_2.7.3 not defined in file libxml2.so.2
with link time reference

I can't be sure(no logs) but VMWare Workstation seems to have been affected
here too, can't get it to work anymore.

Other people having the same problem:
http://ubuntuforums.org/showthread.php?t=1307864
https://bugs.launchpad.net/ubuntu/+bug/461105

This looks like an install from the 1-clicks, right? It looks to me
that it's not karmic-compatible - try installing the debian packages
instead (should be a simple apt-get install postgresql-8.4 - it's
included by default in Karmic IIRC). I've done that many times without
any issues like this.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

On 28/11/2009 7:10 PM, Magnus Hagander wrote:

On Sat, Nov 28, 2009 at 11:53, Leonardo Camargo
<camargoleonardo@gmail.com> wrote:

Hi all,
I'm wondering if someone here know how to go about fixing this problem that
apparently affects everyone who manually install Postgresql8.4 on Ubuntu
Karmic(9.10).

Postgres installation seems to mess with something that renders other
applications unable to function. For instance my problem is with Evolution
Mail. This is the output I started getting after installing postgres:

evolution: /opt/PostgreSQL/8.4/lib/libxml2.so.2: no version information
available (required by evolution)

This looks like an install from the 1-clicks, right? It looks to me
that it's not karmic-compatible - try installing the debian packages
instead (should be a simple apt-get install postgresql-8.4 - it's
included by default in Karmic IIRC). I've done that many times without
any issues like this.

It's not just incompatible - it's a very poorly behaved installer. It's
apparently adding /opt/PostgreSQL/8.4/lib/ to /etc/ld.so.conf or
modifying the global LD_LIBRARY_PATH.

*BAD IDEA*

If you install any libraries not private to the application *and* very
carefully versioned by soname, you shouldn't be making them visible to
the system linker. If you do, things like this happen. This is a
particularly apalling mistake with such common libraries as libxml2,
which are typically not only used by other apps, but provided as part of
the core packages in the system.

If you need to provide your own versions of such libraries, keep them in
a private directory that's never added to the system linker path.
Executables that need access to them should use rpath linking to access
them if at all possible.

If for some reason you won't or can't use rpath linking, which was
designed to solve this problem, you should use wrapper scripts instead.
Eg, if "psql" required access to libxml2, it could be wrapped as:

#!/bin/sh
PGDIR=/opt/PostgreSQL/8.4/
LD_LIBRARY_PATH="${PGDIR}/lib:${LD_LIBRARY_PATH}"\
"${PGDIR}/bin.real/psql" "#@"

where "bin.real/psql" is the real psql binary, which does not appear on
the PATH. Note that the above exactly preserves all command line args,
and will handle spaces in paths etc without issues.

Another alternative if rpath linking is for some reason rejected and
wrapper scripts are considered (understandably) too ugly is to build
your own versions of the libraries you need with different names that'll
be completely unique, eg pg841libxml2.so . You'll run into some *ugly*
global static data issues this way, though, if other code (possibly user
or plugin code) loads a system version of the same library and it has
any global statics.

So - just use rpath linkage for your added libraries, storing them in a
private directory. Please.

(IMO this is about the only area Windows has a significant advantage in
linking by the way - it loads shared libraries from the directory in
which a binary resides preferentially to all others. There'd be security
issues doing so on *nix, but I'm pretty sure they could be worked around
with appropriate ownership and permissions checks).

--
Craig Ringer

So - just use rpath linkage for your added libraries, storing them in a
private directory. Please.

Argh. It's worse than I hoped.

Libraries the One-Click installer tramples all over include:

libxml2
libssl
libcrypto
libreadline
libtermcap
libuuid

... all of which have the same names and in some cases soversions that
they're likely to have in the OS packages.

As libpq.so.5 is also added to the linker path, if a user has a
distro-packaged version of PostgreSQL which has the same soversion of
libpq then the distro-packaged psql etc is also likely to use the
one-click install's libpq, leading to the potential for all sorts of
exciting breakage if they've been built with different options.

An incomplete list of binaries clearly affected by library conflict
issues such as the libxml one the OP reported is, as checked in my
Ubuntu 9.04 install:

/usr/bin/amstex
/usr/bin/bonobo-browser
/usr/bin/bug-buddy
/usr/bin/compiz.real
/usr/bin/devhelp
/usr/bin/dvd95
/usr/bin/dwell-click-applet
/usr/bin/editor
/usr/bin/ekiga
/usr/bin/eog
/usr/bin/etex
/usr/bin/eview
/usr/bin/evim
/usr/bin/evolution
/usr/bin/evolution-addressbook-export
/usr/bin/ex
/usr/bin/gedit
/usr/bin/gnome-about-me
/usr/bin/gnome-appearance-properties
/usr/bin/gnome-default-applications-properties
/usr/bin/gnome-desktop-item-edit
/usr/bin/gnome-help
/usr/bin/gnome-keyboard-properties
/usr/bin/gnome-open
/usr/bin/gnome-panel
/usr/bin/gnome-phone-manager
/usr/bin/gnome-pilot-make-password
/usr/bin/gnome-text-editor
/usr/bin/gnomevfs-cat
/usr/bin/gnomevfs-copy
/usr/bin/gnomevfs-df
/usr/bin/gnomevfs-info
/usr/bin/gnomevfs-ls
/usr/bin/gnomevfs-mkdir
/usr/bin/gnomevfs-monitor
/usr/bin/gnomevfs-mv
/usr/bin/gnomevfs-rm
/usr/bin/gnome-volume-properties
/usr/bin/gpilot-applet
/usr/bin/gpilotd
/usr/bin/gpilotd-control-applet
/usr/bin/gpilotd-session-wrapper
/usr/bin/gpilot-install-file
/usr/bin/grip
/usr/bin/gthumb
/usr/bin/gview
/usr/bin/gvim
/usr/bin/gvimdiff
/usr/bin/inkscape
/usr/bin/inkview
/usr/bin/jadetex
/usr/bin/latex
/usr/bin/meinproc4
/usr/bin/msgattrib
/usr/bin/msgcat
/usr/bin/msgcmp
/usr/bin/msgcomm
/usr/bin/msgconv
/usr/bin/msgen
/usr/bin/msgexec
/usr/bin/msgfilter
/usr/bin/msgfmt
/usr/bin/msggrep
/usr/bin/msginit
/usr/bin/msgmerge
/usr/bin/msgunfmt
/usr/bin/msguniq
/usr/bin/nautilus
/usr/bin/panel-test-applets
/usr/bin/pdfetex
/usr/bin/pdffonts
/usr/bin/pdfimages
/usr/bin/pdfinfo
/usr/bin/pdfjadetex
/usr/bin/pdflatex
/usr/bin/pdftex
/usr/bin/pdftoabw
/usr/bin/pdftohtml
/usr/bin/pdftoppm
/usr/bin/pdftops
/usr/bin/pdftotext
/usr/bin/php5-cgi
/usr/bin/php-cgi
/usr/bin/pidgin
/usr/bin/pointer-capture-applet
/usr/bin/polkit-gnome-authorization
/usr/bin/recode-sr-latin
/usr/bin/rgview
/usr/bin/rgvim
/usr/bin/rhythmbox
/usr/bin/rview
/usr/bin/rvim
/usr/bin/seahorse
/usr/bin/seahorse-daemon
/usr/bin/test-moniker
/usr/bin/tracker-search-tool
/usr/bin/vi
/usr/bin/view
/usr/bin/vim
/usr/bin/vimdiff
/usr/bin/vim.gnome
/usr/bin/vinagre
/usr/bin/vino-preferences
/usr/bin/virsh
/usr/bin/virt-viewer
/usr/bin/xfce4-keyboard-settings
/usr/bin/xfce4-settings-helper
/usr/bin/xgettext
/usr/bin/xmlcatalog
/usr/bin/xmllint
/usr/bin/yelp

Other distros will experience different breakage. On Ubuntu 9.10, for
example, the standard readline soversion is .5.2 so the libreadline.so.4
bundled in the oc installer won't break users of the distro-packaged
libreadline. Ditto libssl and libcrypto (oc: .5.2 ; distro: .0.9.8 ).

This needs really urgent attention. Step 1 is probably to rebuild the
installer using libraries where everything has been given custom
soversions; next step is to use rpath linkage to solve the problem properly.

--
Craig Ringe

Libraries the One-Click installer tramples all over include:

libxml2
libssl
libcrypto
libreadline
libtermcap
libuuid

Apart from libxml2 (which is now being fixed) all other libraries you
mentioned , dint get installed (or copied) to the PGHOME/lib directory
if the same name library already present in the system (/lib and /usr/lib).

... all of which have the same names and in some cases soversions that
they're likely to have in the OS packages.

As libpq.so.5 is also added to the linker path, if a user has a
distro-packaged version of PostgreSQL which has the same soversion of
libpq then the distro-packaged psql etc is also likely to use the
one-click install's libpq, leading to the potential for all sorts of
exciting breakage if they've been built with different options.

An incomplete list of binaries clearly affected by library conflict
issues such as the libxml one the OP reported is, as checked in my
Ubuntu 9.04 install:

/usr/bin/amstex
/usr/bin/bonobo-browser
/usr/bin/bug-buddy
/usr/bin/compiz.real
/usr/bin/devhelp
/usr/bin/dvd95
/usr/bin/dwell-click-applet
/usr/bin/editor
/usr/bin/ekiga
/usr/bin/eog
/usr/bin/etex
/usr/bin/eview
/usr/bin/evim
/usr/bin/evolution
/usr/bin/evolution-addressbook-export
/usr/bin/ex
/usr/bin/gedit
/usr/bin/gnome-about-me
/usr/bin/gnome-appearance-properties
/usr/bin/gnome-default-applications-properties
/usr/bin/gnome-desktop-item-edit
/usr/bin/gnome-help
/usr/bin/gnome-keyboard-properties
/usr/bin/gnome-open
/usr/bin/gnome-panel
/usr/bin/gnome-phone-manager
/usr/bin/gnome-pilot-make-password
/usr/bin/gnome-text-editor
/usr/bin/gnomevfs-cat
/usr/bin/gnomevfs-copy
/usr/bin/gnomevfs-df
/usr/bin/gnomevfs-info
/usr/bin/gnomevfs-ls
/usr/bin/gnomevfs-mkdir
/usr/bin/gnomevfs-monitor
/usr/bin/gnomevfs-mv
/usr/bin/gnomevfs-rm
/usr/bin/gnome-volume-properties
/usr/bin/gpilot-applet
/usr/bin/gpilotd
/usr/bin/gpilotd-control-applet
/usr/bin/gpilotd-session-wrapper
/usr/bin/gpilot-install-file
/usr/bin/grip
/usr/bin/gthumb
/usr/bin/gview
/usr/bin/gvim
/usr/bin/gvimdiff
/usr/bin/inkscape
/usr/bin/inkview
/usr/bin/jadetex
/usr/bin/latex
/usr/bin/meinproc4
/usr/bin/msgattrib
/usr/bin/msgcat
/usr/bin/msgcmp
/usr/bin/msgcomm
/usr/bin/msgconv
/usr/bin/msgen
/usr/bin/msgexec
/usr/bin/msgfilter
/usr/bin/msgfmt
/usr/bin/msggrep
/usr/bin/msginit
/usr/bin/msgmerge
/usr/bin/msgunfmt
/usr/bin/msguniq
/usr/bin/nautilus
/usr/bin/panel-test-applets
/usr/bin/pdfetex
/usr/bin/pdffonts
/usr/bin/pdfimages
/usr/bin/pdfinfo
/usr/bin/pdfjadetex
/usr/bin/pdflatex
/usr/bin/pdftex
/usr/bin/pdftoabw
/usr/bin/pdftohtml
/usr/bin/pdftoppm
/usr/bin/pdftops
/usr/bin/pdftotext
/usr/bin/php5-cgi
/usr/bin/php-cgi
/usr/bin/pidgin
/usr/bin/pointer-capture-applet
/usr/bin/polkit-gnome-authorization
/usr/bin/recode-sr-latin
/usr/bin/rgview
/usr/bin/rgvim
/usr/bin/rhythmbox
/usr/bin/rview
/usr/bin/rvim
/usr/bin/seahorse
/usr/bin/seahorse-daemon
/usr/bin/test-moniker
/usr/bin/tracker-search-tool
/usr/bin/vi
/usr/bin/view
/usr/bin/vim
/usr/bin/vimdiff
/usr/bin/vim.gnome
/usr/bin/vinagre
/usr/bin/vino-preferences
/usr/bin/virsh
/usr/bin/virt-viewer
/usr/bin/xfce4-keyboard-settings
/usr/bin/xfce4-settings-helper
/usr/bin/xgettext
/usr/bin/xmlcatalog
/usr/bin/xmllint
/usr/bin/yelp

Other distros will experience different breakage. On Ubuntu 9.10, for
example, the standard readline soversion is .5.2 so the libreadline.so.4
bundled in the oc installer won't break users of the distro-packaged
libreadline. Ditto libssl and libcrypto (oc: .5.2 ; distro: .0.9.8 ).

This needs really urgent attention. Step 1 is probably to rebuild the
installer using libraries where everything has been given custom
soversions; next step is to use rpath linkage to solve the problem properly.

--
Craig Ringe

--
Regards,
Sachin Srivastava
EnterpriseDB <http://www.enterprisedb.com&gt;, the Enterprise Postgres
<http://www.enterprisedb.com&gt; company.

On Sun, Nov 29, 2009 at 16:18, Sachin Srivastava
<sachin.srivastava@enterprisedb.com> wrote:

Libraries the One-Click installer tramples all over include:

libxml2
libssl
libcrypto
libreadline
libtermcap
libuuid

Apart from libxml2 (which is now being fixed) all other libraries you
mentioned , dint get installed (or copied) to the PGHOME/lib directory if
the same name library already present in the system (/lib and /usr/lib).

What happens if they are installed by the packaging system later on?
Won't that cause a conflict then?

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

On Sun, Nov 29, 2009 at 4:17 PM, Magnus Hagander <magnus@hagander.net> wrote:

On Sun, Nov 29, 2009 at 16:18, Sachin Srivastava
<sachin.srivastava@enterprisedb.com> wrote:

Apart from libxml2 (which is now being fixed) all other libraries you
mentioned , dint get installed (or copied) to the PGHOME/lib directory if
the same name library already present in the system (/lib and /usr/lib).

What happens if they are installed by the packaging system later on?
Won't that cause a conflict then?

Or if the user later uninstalls those libraries -- which can happen
automatically when nothing in the packaging system depends on them any
longer.

But i don't see what the conflict is if they're installed in
PGHOME/lib as long as the installer doesn't fiddle with
/etc/ld.so.conf or set any environment variables. The binaries should
just be built with an rpath pointing to that directory or ship with a
startup script which puts that directory in LD_LIBRARY_PATH. Whether
you want to append, leaving the system directories ahead of the
one-click installed libraries, or prepend so the linker always uses
your libraries would depend on how you want it to behave. Setting
rpath is equivalent to prepending I believe.

--
greg

Magnus Hagander wrote:

On Sun, Nov 29, 2009 at 16:18, Sachin Srivastava
<sachin.srivastava@enterprisedb.com> wrote:

Libraries the One-Click installer tramples all over include:

libxml2
libssl
libcrypto
libreadline
libtermcap
libuuid

Apart from libxml2 (which is now being fixed) all other libraries you
mentioned , dint get installed (or copied) to the PGHOME/lib directory if
the same name library already present in the system (/lib and /usr/lib).

What happens if they are installed by the packaging system later on?
Won't that cause a conflict then?

What if the libraries installed by the system package manager have been
built with different options that render them incompatible with the
shipped PostgreSQL binaries? Possibly subtly so, with crashes or data
corruption down the track rather than immediate and obvious failure?

(Arguably the soname should be changed in this case, but in practice the
soname just isn't sufficient for this sort of thing - you need some kind
of "build key" and there's no support in GNU ld and ld.so for such).

I'd say "ffs, just enable rpath" but for the fact that without a wee bit
more work it doesn't handle moving binaries around very well. Mac OS X's
"@executable_path" runtime linker path substitution doesn't seem to have
a standard equivalent on general *nix. Thankfully, GNU ld.so does offer
a similar runtime path substitution - the ${ORIGIN} variable. From the
ld.so manpage:

$ORIGIN
ld.so understands the string $ORIGIN (or equivalently
${ORIGIN}) in an rpath specification to mean the
directory containing the application executable.
Thus, an application located in somedir/app could be
compiled with gcc -Wl,-rpath,'$ORIGIN/../lib' so that
it finds an associated shared library in somedir/lib
no matter where somedir is located in the directory
hierarchy.

(There's also some other good stuff under "RPATH TOKEN EXPANSION". If
you haven't read the entirety of the ld.so and ld man pages, you need to
do so *now* if you're packaging apps for binary distribution).

Note that you can build without rpath, or with normal rpaths, and change
them later using the commonly-available chrpath too. For that matter,
you can skip using $ORIGIN and just use a bundled copy of chrpath to set
rpaths on your binaries at install-time.

http://linux.die.net/man/1/chrpath

So, please, please, PLEASE start using rpath linkage and stop adding
your lib dir to ld.so.conf ! This problem has been around - and solved -
for a very long time, and you'd be much better off using the existing
well-established and robust solutions rather than rolling your own
dangerous workarounds.

--
Craig Ringer

Greg Stark wrote:

But i don't see what the conflict is if they're installed in
PGHOME/lib as long as the installer doesn't fiddle with
/etc/ld.so.conf or set any environment variables. The binaries should
just be built with an rpath pointing to that directory or ship with a
startup script which puts that directory in LD_LIBRARY_PATH.

In fact, it looks like the EnterpriseDB init scripts *already* set
LD_LIBRARY_PATH when starting the postgresql daemon, despite having also
messed with ld.so.conf . It's a weird half-and-half approach.

I've tested the distribution with ${ORIGIN} based rpath linking without
issues.

Until EnterpriseDB get around to fixing this in their packages, if you
or anyone else need to fix a one-click PostgreSQL-on-Linux binary
install, just make sure chrpath is installed (eg: apt-get install
chrpath) then run the following:

cd /opt/PostgreSQL/8.4
sudo -v
for f in `file * | grep ELF | cut -d : -f 1 `; do
sudo chrpath --replace "\${ORIGIN}/../lib" $f
done
sudo rm -f /etc/ld.so.conf.d/postgresql-8.4
sudo ldconfig

... which will remove the edb-installed libs from the global search path
and will set the edb binaries to preferentially use the copies of the
libs that came with the distribution. Note that this will change the
checksum of the binaries.

*** TO FIX THIS IN THE EDB ONECLICK DISTRIBUTION ***:

Just build the Pg binaries for the distribution as normal. Once you've
built the binaries and installed to a staging directory, use chrpath to
edit the rpath setting as above, so that the binaries know where to look
for their libraries. Remove /etc/ld.so.conf.d/postgresql-8.4 from the
installer package. Remove setting of LD_LIBRARY_PATH from the init script.

Finally, please rename /etc/init.d/postgresql-8.4 to something that
*doesn't* clobber a distro-installed initscript, like say
/etc/init.d/postgresql-oneclick-8.4 .

*grumbles and restores his original init script from backups after it
was clobbered by the edb installer*

Whether
you want to append, leaving the system directories ahead of the
one-click installed libraries, or prepend so the linker always uses
your libraries would depend on how you want it to behave. Setting
rpath is equivalent to prepending I believe.

It is. It's also much, much safer to do things that way, because a lib
with the same name but incompatible configuration won't land up being
unexpectedly loaded.

--
Craig Ringer