Re: libpq.so.4

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: pgsql-general(at)postgresql(dot)org
Cc: "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at>, "Oliver Kohll *EXTERN*" <oliver(at)gtwm(dot)co(dot)uk>
Subject: Re: libpq.so.4
Date: 2008-06-08 20:27:10
Message-ID: 200806082227.11212.peter_e@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Nathan Boley 2008-06-08 20:39:59 Re: full vacuum really slows down query
Previous Message Albe Laurenz 2008-06-08 19:46:49 Re: libpq.so.4