Обсуждение: libpq.so.4

Oliver Kohll <oliver@gtwm.co.uk> writes:
> What I've thought of trying so far is
> 1) creating a symlink called libpq.so.4 towards libpq.so.5 - slightly
> dangerous due to possible API changes?

Worth trying.  According to the CVS logs
http://archives.postgresql.org/pgsql-committers/2006-04/msg00341.php
the ABI break from .4 to .5 was simply to stop exporting symbols that
weren't officially part of the API.  So a symlink would work for
applications that played by the rules, and if you have any that
didn't the failure will be pretty obvious.

> 2) extracting a copy of libpq.so.4 from the previous RPM release of
> postgres and manually uploading it

That would work too.

> 3) building a custom compat package - I don't know how to do this
> though.

If you got the 8.3 package from someplace they should have an 8.1
compat package too.

            regards, tom lane

Oliver Kohll wrote:
> I have the same issue as this poster with libpq.so.4:
> http://www.nabble.com/8.3.0-upgrade-td16093803.html
>
> In short, I've upgraded to 8.3.1 from 8.1 on RHEL 4 (with
> some CentOS packages). I have apps with dependencies of
> libpq.so.4 but this is no longer available. 8.3.1 provides
> libpq.so.5 and the compat-libs provide libpq.so.3.

Strange; does anybody know why?

> At the moment maintaining package management integrity is not
> a must - getting back to 100% package-controlled files can
> wait until the machine is replaced. Upgrading the dependent
> software is not an option.
> With that in mind, any suggestions on options?
>
> What I've thought of trying so far is
> 1) creating a symlink called libpq.so.4 towards libpq.so.5 -
> slightly dangerous due to possible API changes?

Don't even think about it.

> 2) extracting a copy of libpq.so.4 from the previous RPM
> release of postgres and manually uploading it

You can do that if all else fails.

> 3) building a custom compat package - I don't know how to do
> this though.

Then that's probably not an option for you...

Yours,
Laurenz Albe

Am Sunday, 8. June 2008 schrieb Albe Laurenz:
> > In short, I've upgraded to 8.3.1 from 8.1 on RHEL 4 (with
> > some CentOS packages). I have apps with dependencies of
> > libpq.so.4 but this is no longer available. 8.3.1 provides
> > libpq.so.5 and the compat-libs provide libpq.so.3.
>
> Strange; does anybody know why?

Well, it appears to me that the RPM packaging was/is not done with much
planning and foresight.  Back then libpq.so.3 was transitioned to libpq.so.4,
someone was kind enough to provide a compatibility package to serve those
people with packages still referencing libpq.so.3.  So then when libpq.so.5
came around, this scheme collapsed, because then "compat" could refer to
libpq.so.3 or .4, depending on what exactly you want to be "compatible" to,
which may in turn depend on the release cycles of the underlying operating
system.

So today, depending on whose packages you take, for what PostgreSQL version
and operating system they were intended, postgresql-libs and compat-libs can
refer to pretty much anything and may or may not be able to coexist.

A workable fix, at least from the point of view of a Debian developer, is to
put the soname number into the package name (libpq3, libpq4, libpq5, etc.),
thus making them unique and coinstallable for all times.

Hi,

On Sun, 2008-06-08 at 11:55 +0100, Oliver Kohll wrote:
<snip>
> 3) building a custom compat package - I don't know how to do this
> though.

These are probably my packages from http://yum.pgsqlrpms.org , and I
thought I already fixed this issue -- I'll check.

Anyway,

http://yum.pgsqlrpms.org/8.3/redhat/rhel-4-x86_64/repoview/compat-postgresql-libs.html

and

http://yum.pgsqlrpms.org/8.3/redhat/rhel-4-i386/repoview/compat-postgresql-libs.html

now has compat-libs-postgresql-4 packages.

Regards,
--
Devrim GÜNDÜZ , RHCE
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/

Peter Eisentraut <peter_e@gmx.net> writes:
> A workable fix, at least from the point of view of a Debian developer, is to
> put the soname number into the package name (libpq3, libpq4, libpq5, etc.),
> thus making them unique and coinstallable for all times.

FWIW, the package names Red Hat has been using for compat libraries are
    postgresqlclient7
        postgresqlclient81
It might have been more consistent to call the first one
postgresqlclient74, but that's where we are ...

            regards, tom lane