Re: libpq.so.4 - Mailing list pgsql-general

From Peter Eisentraut
Subject Re: libpq.so.4
Date
Msg-id 200806082227.11212.peter_e@gmx.net
Whole thread Raw
In response to Re: libpq.so.4  ("Albe Laurenz" <laurenz.albe@wien.gv.at>)
Responses Re: libpq.so.4  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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.

pgsql-general by date:

Previous
From: "Albe Laurenz"
Date:
Subject: Re: libpq.so.4
Next
From: "Nathan Boley"
Date:
Subject: Re: full vacuum really slows down query