Re: Providing libpq explicitly

On 11 October 2016 at 15:13, Devrim Gündüz <devrim(at)gunduz(dot)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