Subject: Providing libpq explicitly

From: Devrim Gündüz <[email-masked]>
Date: Mon, 10 Oct 2016 09:44:06 +0300

Hi Craig,

Around Sep 2014, I committed a patch of yours that remove explicit 

Provides: libpq.so

from the PostgreSQL RPMs, for 9.4 beta2. Do you remember the reason behind
this?

For 3rd party apps that depend on specific version of libpq (I mean like "libpq
>= 9.1", not libpq.so.5) are broken now. Would you mind if I put it back to the
community RPMs?

Thanks!

Regards,
-- 
Devrim GÜNDÜZ
EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

---

From: Craig Ringer <[email-masked]>
Date: Mon, 10 Oct 2016 15:20:49 +0800

> from the PostgreSQL RPMs, for 9.4 beta2. Do you remember the reason behind

Honestly, I don't have the foggiest anymore.

>>= 9.1", not libpq.so.5) are broken now. Would you mind if I put it back to the

I'd argue that such packages are simply incorrectly packaged. There's
no such thing as "libpq 9.1".

They should be using rpm's automatic library dependencies to ensure
that dependency, and shouldn't declare an explicit dependency.

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

-- 
Sent via pgsql-pkg-yum mailing list ([email-masked])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-pkg-yum

---

From: Devrim Gündüz <[email-masked]>
Date: Mon, 10 Oct 2016 10:28:17 +0300

Hi Craig,

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

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

Regards,

---

From: Craig Ringer <[email-masked]>
Date: Mon, 10 Oct 2016 19:45:36 +0800

> RPMs", for example, and prevents users to be able to install PostgreSQL < 9.0:

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.

---

From: Peter Eisentraut <[email-masked]>
Date: Mon, 10 Oct 2016 21:59:26 -0400

>> >= 9.1", not libpq.so.5) are broken now. Would you mind if I put it back to the

What is an example of such a package?

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

---

From: Devrim Gündüz <[email-masked]>
Date: Tue, 11 Oct 2016 10:13:53 +0300

> What is an example of such a package?

One of EDB packages. It uses functions exported by the libpq of 9.1+.

Regards,

---

From: Craig Ringer <[email-masked]>
Date: Tue, 11 Oct 2016 15:33:45 +0800

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

---

From: Peter Eisentraut <[email-masked]>
Date: Wed, 12 Oct 2016 09:37:43 -0400

On 10/11/16 3:33 AM, Craig Ringer wrote:
> libpq.

Surely the RPM world has a standard or convention for this so we don't
have to make up something here?  This is not the first shared library in
the world, after all

---

From: Devrim Gündüz <[email-masked]>
Date: Fri, 28 Oct 2016 10:31:42 +0300

Hi,

> have to make up something here?  This is not the first shared library in

Noticing that we already provide postgresql-libs (versionless), I made a small
change in the spec file, and appended version number to that provides. It won't
break our packages, and then make EDB's package happy. So, no changes in
libpq.so part.

Thank you!

Regards,