Adam Lang wrote:
> It actually runs without the symlink and --nodeps
The reason it runs but won't install is due to the way the RPM build
process follows symlinks versus the way ld.so treats symlinks. The
actual linked file is simply libpq.so -- but the RPM findrequires script
(which you can look at yourself in /usr/lib/rpm) resolves the symlink
and places the dependency on the actual lib -- in this case,
libpq.so.2.0. It does this for versioning, as ld.so is version-agnostic.
Well, since libpq.so.2.1 is not that different from 2.0, it works fine
-- however, if you had an app linked against libpq.so.1.0 (which would
be true if you used a binary RPMset from RedHat 5.x contribs that linked
against the RH 5 PostgreSQL 6.3.2), then you might run into some
mysterious problems as libpq.so.2.1 is dynalinked into an app that is
expecting libpq.so.1.0. Or worse yet, you could use an app linked
against Postgres95 1.01's libpq.so (which is STILL libpq.so as far as
ld.so is concerned) -- and then you are guaranteed to have problems
(been there, done that).
The ld.so linker, of course, doesn't care -- it just loads libpq.so in
the LD_PATH and goes on with its life. That's why RPM enforces
dependencies -- and why there is a --nodeps switch for when you need it
-- as long as you are prepared to deal with the potential
incompatibilities.
Of course, in this particular instance it works due to the low mismatch
from 2.0 to 2.1 libpq.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11