Re: Providing libpq explicitly - Mailing list pgsql-pkg-yum

From Craig Ringer
Subject Re: Providing libpq explicitly
Date
Msg-id CAMsr+YFjeziUMp-w+07BRfRDQySD0S2Lzn5nyVEYa_gNhQDMFg@mail.gmail.com
Whole thread Raw
In response to Re: Providing libpq explicitly  (Devrim Gündüz <devrim@gunduz.org>)
List pgsql-pkg-yum
On 10 October 2016 at 15:28, Devrim Gündüz <devrim@gunduz.org> wrote:
>
> Hi Craig,
>
> On Mon, 2016-10-10 at 15:20 +0800, Craig Ringer wrote:
>> I'd argue that such packages are simply incorrectly packaged. There's
>> no such thing as "libpq 9.1".
>
> Well, this actually "works". This means "libpq provided by PostgreSQL 9.1
> RPMs", for example, and prevents users to be able to install PostgreSQL < 9.0:
>
> =========================================
>            Requires: libpq.so >= 9.0
>            Available: postgresql-libs-8.4.20-6.el6.i686 (base)
>                libpq.so = 8.4.20-6.el6
>  You could try using --skip-broken to work around the problem.
>
> =========================================
>> They should be using rpm's automatic library dependencies to ensure
>> that dependency, and shouldn't declare an explicit dependency.
>
> Then, they would need to generate RPMs for each PostgreSQL version just for
> this piece, and it creates other problems.

Huh? Why?

If the soname is the same (which it must be for linking to work) and
the target library version is >= the one it was built against (which
it should be to be compatible) then it'll be fine. Otherwise it won't
work because it shouldn't work.

At minimum it should be Provides: libpq not Provides: libpq.so  .

But in the end, since I can't even remember the original reason to get
rid of it, if you put it back it's your call.


--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-pkg-yum by date:

Previous
From: Devrim Gündüz
Date:
Subject: Re: Providing libpq explicitly
Next
From: Peter Eisentraut
Date:
Subject: Re: Providing libpq explicitly