So you're saying that If I install applications from RPMs, for it to really
install properly, the dependencies should be installed from RPMs also? It
can be done without (as in the example prior), but it makes life more
difficult?
Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
----- Original Message -----
From: "Lamar Owen" <lamar.owen@wgcr.org>
To: "Adam Lang" <aalang@rutgersinsurance.com>; "PGSQL General"
<pgsql-general@postgresql.org>
Sent: Thursday, September 07, 2000 3:40 PM
Subject: Re: [GENERAL] php and pgsql and rpm/compile
> Lamar Owen wrote:
> > 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.
>
> Oh, and the reason just adding the symlink in-place into the filesystem
> won't work is due to the fact that the RPM dependency checking doesn't
> check the filesystem's actual state -- it checks the rpm database's idea
> of what the filesystem looks like -- thus, you actually have to have a
> package installed that contains 'libpq.so.2.0' in order to get it to
> pass dependency checking. This is one reason that installing from RPM
> is the best idea on an RPM-based system (of course, currently SuSE won't
> install a RedHat RPM primarily due to the dep on chkconfig that is in
> the RedHat RPM). If you install from a source tarball, then install an
> RPM that depends on libs in your from-source installation (that the rpm
> database doesn't know about), it fails due to the unknown deps.
>
> --
> Lamar Owen
