Bug 206046 - databases/postgresql92-server: Add missing perl dependency
Summary: databases/postgresql92-server: Add missing perl dependency
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: pgsql
Keywords: easy, needs-qa, patch
Depends on:
Blocks: 206049
  Show dependency treegraph
Reported: 2016-01-08 21:16 UTC by Christoph Moench-Tegeder
Modified: 2016-01-31 13:37 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (pgsql)
koobs: merge-quarterly?

make perl known to pgxs (429 bytes, patch)
2016-01-08 21:16 UTC, Christoph Moench-Tegeder
no flags Details | Diff
failed build of postgis22 in poudriere (1.54 KB, text/plain)
2016-01-09 14:18 UTC, Christoph Moench-Tegeder
no flags Details
pgxs Makefile.global from default (unpatched) postgresql95-client build (25.97 KB, text/plain)
2016-01-09 14:20 UTC, Christoph Moench-Tegeder
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Moench-Tegeder freebsd_committer 2016-01-08 21:16:59 UTC
Created attachment 165282 [details]
make perl known to pgxs

All postgresql client ports check their build environment for perl and record the location of the perl interpreter in the pgxs Makefile - or the register a missing perl binary. Dependent ports may exhibit funny failures if they try to use perl via the PGXS framework, this affects mostly PostgreSQL extensions.
This one was quite some trouble to debug, as "PostgreSQL built in the base system" did have a perl, but with the minimal build environment under poudriere pgxs has a "missing" perl.
Attached trivial patch provides the configured default perl interpreter, which makes pgxs register the interpreter, ready to use for extensions.
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2016-01-09 08:07:08 UTC
@Christoph, I wonder if this could/should be handled in the postgresql ports framework, rather than individual ports, given all clients require it. Thoughts?

Can you also provide an example (as attachment) of how an extension fails when perl is not available?
Comment 2 Palle Girgensohn freebsd_committer 2016-01-09 09:27:38 UTC

The missing script is installed verbatim, so it really creates a snapshot of the reality at the moment when it is run, not when postgresql is built.

Hence I don't get it really, why would we depend on perl for that reason? The missing script does not save it's result at build time.

In the missing script, here's what missing says if there is no perl in the path:

ERROR: Perl is missing on your system. It is needed unless you are building
from an unmodified official distribution of PostgreSQL.

From the postgresql port's view, this is fine. It does not need perl.

If a client port checks the localtion of perl it seems to med that it is the client port that requires perl?

But maybe I am missing something here?
Comment 3 Christoph Moench-Tegeder freebsd_committer 2016-01-09 14:18:36 UTC
Created attachment 165315 [details]
failed build of postgis22 in poudriere
Comment 4 Christoph Moench-Tegeder freebsd_committer 2016-01-09 14:20:00 UTC
Created attachment 165316 [details]
pgxs Makefile.global from default (unpatched) postgresql95-client build
Comment 5 Christoph Moench-Tegeder freebsd_committer 2016-01-09 14:26:44 UTC
It was a little late yesterday, so perhaps I wasn't really clear what happened.

The attached postgis22 build log extract shows how the build of the postgis "address standardizer" module fails with "ERROR: Perl is missing on your system" - this is the basic issue I wanted to get fixed here.

The attached Makefile.global (from ${PREFIX}/lib/postgresql/pgxs/src/Makefile.global, packaged by postgresql*-client) shows the problem in line 292 - perl wasn't found at postgresql build time, so the pgxs extension build system cannot use perl, regardless wehther perl is installed at extension build time.

My fix results in the following change to Makefile.global:
--- pkg95-plain/usr/local/lib/postgresql/pgxs/src/Makefile.global       2016-01-09 15:09:48.000000000 +0100
+++ pkg95-fixed/usr/local/lib/postgresql/pgxs/src/Makefile.global       2016-01-08 22:26:00.000000000 +0100
@@ -289,9 +289,9 @@
 # Perl
-ifneq (,)
+ifneq (/usr/local/bin/perl,)
     # quoted to protect pathname with spaces
-    PERL               = ''
+    PERL               = '/usr/local/bin/perl'
     PERL               = $(missing) perl
Comment 6 Christoph Moench-Tegeder freebsd_committer 2016-01-09 14:28:05 UTC
(In reply to Kubilay Kocak from comment #1)

Currently, all the postgresql*-{client,server,contrib} Makefiles include postgresql92-server/Makefile - so this Makefile essentially is the infrastructure :)
Comment 7 Palle Girgensohn freebsd_committer 2016-01-11 11:24:37 UTC
(In reply to Christoph Moench-Tegeder from comment #5)

Ah, yes, I was missing something. Thanks for enlightening me. :-)

I would really have preferred that the perl check was not there at all, since it means we *have* to depend on perl in order to be correct and stringent. 

So the short term solution seems to be adding USES= perl5 and bump PORTREVISION for all postgresql??-server ports. 

I'd rather not depend on perl at all, but that would require removing the check from pgxs altogether, which may be worse...

A bit off topic, this question should really be asked att pgsql-hackers@, but can anyone here explain why that check is *there*? What is the motive for saving the path to perl in the pgxs makefile framework? Or for awk or anything else for that matter? Couldn't the few ports that depend on perl check the path themselves?
Comment 8 Christoph Moench-Tegeder freebsd_committer 2016-01-11 15:01:58 UTC
(In reply to Palle Girgensohn from comment #7)

Um. PGXS Makefile.global is just postgresql's src/Makefile.global - compare ${PREFIX}/lib/postgresql/pgxs/src/Makefile.global and postgresql/src/Makefile.global.in. Extensions may rely on having the same Makefile and variables when building in-tree or via PGXS, so I guess there's no way to just remove the perl block. The reasoning for that will undoubtedly be something like "there are platforms where the right perl version is not always in $PATH" - myself remembers the wild undergrowth in /opt and the mess of having several $something installations (including perl) on one system.

I'd really like it to just build-depend on perl (we would get the right PERL variable in Makefile.global), but Uses/perl5.mk does not have that option,
so it's no perl at all or unconditionally installing perl. OTOH I believe that it's very hard to avoid perl completely, so we don't make matters (much) worse.
Comment 9 commit-hook freebsd_committer 2016-01-13 10:36:38 UTC
A commit references this bug:

Author: girgen
Date: Wed Jan 13 10:36:24 UTC 2016
New revision: 406034
URL: https://svnweb.freebsd.org/changeset/ports/406034

  Some binaries where moved from contrib to base in 9.5, like pgbench and
  pg_upgrade. Other where added in 9.5, but the port failed to install them.
  Make sure they are properly installed by the correct port (-client or -server) [1]

  Remove unused and hence confusing OSSP_UUID parameters from Makefile [2]

  Add options to allow user to be set for the backup script in periodic.
  Add this option only to 9.5 for now. It will be updated to other servers at
  next regular patch release. [3]

  The path to perl in hard coded into pgxs/src/Makefile.global which is
  then installed. Hence, we must depend on perl when that file is installed.

  Noticed by:	Paul Guyot [1]
  PR:		192387 [2]
  PR:		172110 [3]
  PR:		206046 [4]

Comment 10 Palle Girgensohn freebsd_committer 2016-01-13 10:42:23 UTC
Add perl dependency to the postgresql-9?-clients and bumping PORTREVION. Thanks for pointing it out.
Comment 11 commit-hook freebsd_committer 2016-01-31 13:37:35 UTC
A commit references this bug:

Author: girgen
Date: Sun Jan 31 13:36:49 UTC 2016
New revision: 407633
URL: https://svnweb.freebsd.org/changeset/ports/407633

  MFH: r406034 (partly)

  Remove unused and hence confusing OSSP_UUID parameters from Makefile [2]

  The path to perl in hard coded into pgxs/src/Makefile.global which is
  then installed. Hence, we must depend on perl when that file is installed.

  PR:		192387 [2]
  PR:		206046 [4]
  Approved by:	portmgr

_U  branches/2016Q1/