Bruce Momjian wrote:
> > A symlink works around the problem, if the symlink is part of the RPM so
> > that it gets in the rpm dep database. Of course, this only causes
> > problems with RedHat 6.2 and earlier, as RH 7's PHP stuff was built
> > against 7.0.2 to start with. But, 7.1 with libpq.so.2.2 will cause
> > similar dep failures for PHP packages built against 7.0.2.
> For us, it would be great if libpq.so.2.1 linked against the
> libpq.so.2.1, libpq.so.2.2, but not libpq.so.2.0. I would guess other
> apps need this ability too. How do they handle it?
If I were doing manual dependencies for the other packages, I would say:
Requires: libpq.so => 2.1
No as to whether that works or not, I don't know. I know it won't work
with RPM prior to 3.0.4 or so.
> I saw someone installing pgaccess from RPM. It wanted tcl/tk 8.0, and
> they had tcl/tk 8.3 installed, and it failed. Seems this is a common
> RPM problem.
Well, actually, there are times you might not want greater than a
certain version. And you as a packager can make certain dependency
requirements manually. However, this libpq.so.2.0 vs 2.1 failure was an
automatic dependency.
And, really, RPM shouldn't allow it for automatic requires. Suppose I
have an ancient client RPM that I want to install. Assuming for one
second that nothing else has changed on the system except the PostgreSQL
version, if the client was built against PostgreSQL 6.2.1 with
libpq.so.1, and I force the install of it even though libpq.so.2 is
installed, freakish things can happen. Been there and done that -- a
client linked against Postgres95 1.0.1 did really strange things when
libpq.so.2 was link loaded under it.
Worse things happen if you have a package that requires tcl 7.4 and you
have tcl 8.3.2 installed.
Not everyone is as generous as we are with upwards compatibility.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11