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

From Craig Ringer
Subject Re: Providing libpq explicitly
Date
Msg-id CAMsr+YHGpXA5OYi-V2t82vt58+KuuKy-wy+1hjrtWirSH6RL4g@mail.gmail.com
Whole thread Raw
In response to Re: Providing libpq explicitly  (Devrim Gündüz <devrim@gunduz.org>)
Responses Re: Providing libpq explicitly  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-pkg-yum
On 11 October 2016 at 15:13, Devrim Gündüz <devrim@gunduz.org> wrote:
> On Mon, 2016-10-10 at 21:59 -0400, Peter Eisentraut wrote:
>> What is an example of such a package?
>
> One of EDB packages. It uses functions exported by the libpq of 9.1+.

I see, and you don't want to depend on postgresql9x-libs because you
want to allow install against any postgresql9x-libs that installs a
libpq. It's a binary distribution issue. Fair enough.

You could have alternatives listed in Requires, but that requires
enumerating all postgresql9x variants into the future, which is messy
and fragile.

What should IMO be done here is to add a version on the Provides:
postgresq-llibs that already exists:


$ rpm -q --provides postgresql96-libs
config(postgresql96-libs) = 9.6beta3-1PGDG.f23
libecpg.so.6()(64bit)
libecpg_compat.so.3()(64bit)
libpgtypes.so.3()(64bit)
libpq.so.5()(64bit)
libpqwalreceiver.so()(64bit)
postgresql-libs
postgresql96-libs = 9.6beta3-1PGDG.f23
postgresql96-libs(x86-64) = 9.6beta3-1PGDG.f23


I think it's also fine to have a  versioned

Provides: libpq

but *not* Provides: libpq.so, because that should be rpm autodeps job.
That's likely why I asked for its removal originally; as I said I just
don't remember anymore.

--
 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