Bug 1071971 - Building software against postgresql return mix of version pkgconfig(libpq)
Building software against postgresql return mix of version pkgconfig(libpq)
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Other
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Reinhard Max
E-mail List
Depends on:
  Show dependency treegraph
Reported: 2017-12-08 13:07 UTC by Bruno Friedmann
Modified: 2020-08-13 09:55 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Bruno Friedmann 2017-12-08 13:07:14 UTC
Trying to build mapserver 7 for Tumbleweed is impossible since the introduction of postgresql10 in TW


The spec file contain
BuildRequires:  pkgconfig(libpq)
Requires:  libpq5

Here's the package the build install 

[   11s] [329/386] cumulate postgresql10-10.1-1.2
[   11s] [331/386] cumulate postgresql-10-1.2
[   11s] [349/386] cumulate postgresql96-devel-9.6.5-1.1

Off course the cmake failed to find the installation.

[   40s] CMake Warning at cmake/FindPostgreSQL.cmake:21 (message):
[   40s]   pg_config not found, will try some defaults
[   40s] Call Stack (most recent call first):
[   40s]   CMakeLists.txt:532 (find_package)
[   40s] 
[   40s] 
[   40s] -- Could NOT find POSTGRESQL (missing: POSTGRESQL_INCLUDE_DIR) 
[   40s] CMake Error at CMakeLists.txt:69 (message):
[   40s]   POSTGIS library/component/dependency could not be found.
[   40s] 
[   40s]     HINTS:
[   40s]     - disable POSTGIS support by adding -DWITH_POSTGIS=0
[   40s]     - add the POSTGIS install directory to the CMAKE_PREFIX_PATH variable (-DCMAKE_PREFIX_PATH="/path/to/POSTGIS-install-dir;/path/to/other/dirs"
[   40s] Call Stack (most recent call first):
[   40s]   CMakeLists.txt:547 (report_optional_not_found)

Build the same package for openSUSE_Leap_42.3 give installation of postgresql94-devel and everything works has expected

I've tried to have postgresql-devel in buildrequires but this install an empty package ....
Comment 1 Reinhard Max 2017-12-08 15:24:58 UTC
I have no idea why the buildservice picks postgresql96-devel, given that postgresql10-devel also provides "pkgconfig(libpq)", but with a higher version.
Comment 2 Reinhard Max 2017-12-08 15:38:44 UTC
Hmm, but I do understand now, how postgresql96-devel indirectly pulls postgresql10:

postgresql96-devel Requires(post) postgresql-noarch (for the install-alternatives script), which in turn Requires postgresql-implementation (provided by all postgresqlXX packages) and Recommends postgresql10.

Now when postgresql10 gets installed, update-alternatives switches to it, which removes the link from /usr/bin/pg_config (via /etc/alternatives) to /usr/lib/postgresql96/bin/pg_config .
Comment 3 Bruno Friedmann 2017-12-08 16:00:28 UTC
Hi thanks for the analyze ... So we are in a so called "Houston we got a problem" situation :-)

In the repository, I can modify the project config and play with a lot of %if%else as in the spec file. But that mean when postgresql11 will come everything will need to be touched again.

For the other packages I maintain (as they are extensions, I use the multibuild which work great). But for those like mapserver that just need libpq as required I would like to have a safe and longterm solution.
Comment 4 Marcus Rückert 2017-12-08 16:47:09 UTC
we should define a like postgresql_default_version

and recommend that version in postresql(-devel).noarch
Comment 5 Bruno Friedmann 2017-12-13 14:30:36 UTC
I've more than 12 packages stucks and the number are increasing.
did we have a consensus or hack available ?
Comment 6 Reinhard Max 2017-12-13 15:06:26 UTC
(In reply to Marcus Rückert from comment #4)
> we should define a like postgresql_default_version
> and recommend that version in postresql(-devel).noarch

We're doing that already, but call it defaultpackage:

--- snip ---
%define defaultpackage postgresql10
Name:           postgresql
Recommends:     %defaultpackage
%package devel
Recommends:     %defaultpackage-devel
--- snap ---

I see two problems with this:

1. It apparently doesn't work, or we won't have this bug.

2. The defaults for building client packages against and for installation might be different, i.e. building against the oldest possible version for compatibility reasons and installing the newest possible version to get the latest features.
Comment 7 Marcus Rückert 2017-12-13 18:19:48 UTC
osc rdiff {,home:darix:branches:}server:database:postgresql/postgresql

but we will still need a:

Prefer: postgresql-devel-implementation postgresql10-devel

As the OBS scheduler ignores the Recommends: in the spec file

test package:

Comment 8 Marcus Rückert 2017-12-13 18:30:44 UTC
mls: can we have the OBS handle constructs like this?

%define defaultpackage postgresql10

%package devel
Requires:       postgresql-devel-implementation
Recommends:     %defaultpackage-devel

Currently it seems we need a Prefer in the prjconf to make this work.
Comment 9 Michael Schröder 2017-12-14 09:58:32 UTC
OBS already uses package recommends to break ambiguities. So what else do you need?
Comment 10 Reinhard Max 2017-12-14 10:18:09 UTC
Marcus: As I said in comment 6, for building client packages we wan to prefer the devel package of the oldest available version, not the newest one, assuming that applications compiled using older headers will still work with newer libs of the same soname version, but not necessarily the other way around.

Also, I don't like having to keep the version of the noarch packages in sync with the latest patchlevel release, because normally there is no need to touch the noarch package for every patchlevel update of the implementation package.

Iow, I want the version of the postgresql package to stay at 10 (not 10.0, 10.1, 10.2, etc.) until we introduce a postgresql11 package and make it the new default.
Comment 11 Marcus Rückert 2017-12-14 10:56:34 UTC
(In reply to Michael Schröder from comment #9)
> OBS already uses package recommends to break ambiguities. So what else do
> you need?

for my "osc build" yesterday it did not work until I added a Prefer to the project conf.
Comment 12 Reinhard Max 2017-12-21 10:20:37 UTC
I see that mapserver builds now, so I guess we can close this.
Comment 13 Bruno Friedmann 2017-12-23 08:09:36 UTC
As the published version was no more working, due to some deps rebuilds, I've tricked the project conf to add a postgresql10-devel Prefer for openSUSE >= 1550.

So I'm not sure we have a complete fix, (The bug mentionned by Darix about difference between osc and obs being normally the root cause).