Bug 206046
| Summary: | databases/postgresql92-server: Add missing perl dependency | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Christoph Moench-Tegeder <cmt> | ||||||||
| Component: | Individual Port(s) | Assignee: | pgsql | ||||||||
| Status: | Closed FIXED | ||||||||||
| Severity: | Affects Only Me | CC: | girgen | ||||||||
| Priority: | --- | Keywords: | easy, needs-qa, patch | ||||||||
| Version: | Latest | Flags: | bugzilla:
maintainer-feedback?
(pgsql) koobs: merge-quarterly? |
||||||||
| Hardware: | Any | ||||||||||
| OS: | Any | ||||||||||
| Bug Depends on: | |||||||||||
| Bug Blocks: | 206049 | ||||||||||
| Attachments: |
|
||||||||||
@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? Hi, 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? Created attachment 165315 [details]
failed build of postgis22 in poudriere
Created attachment 165316 [details]
pgxs Makefile.global from default (unpatched) postgresql95-client build
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'
else
PERL = $(missing) perl
endif
(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 :) (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? (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. 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 Log: 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] Changes: head/databases/postgresql90-client/Makefile head/databases/postgresql91-client/Makefile head/databases/postgresql91-server/Makefile head/databases/postgresql92-client/Makefile head/databases/postgresql92-server/Makefile head/databases/postgresql93-client/Makefile head/databases/postgresql94-client/Makefile head/databases/postgresql95-client/Makefile head/databases/postgresql95-contrib/Makefile head/databases/postgresql95-server/Makefile head/databases/postgresql95-server/files/502.pgsql.in head/databases/postgresql95-server/pkg-plist-client head/databases/postgresql95-server/pkg-plist-server Add perl dependency to the postgresql-9?-clients and bumping PORTREVION. Thanks for pointing it out. 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 Log: 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 Changes: _U branches/2016Q1/ branches/2016Q1/databases/postgresql90-client/Makefile branches/2016Q1/databases/postgresql91-client/Makefile branches/2016Q1/databases/postgresql91-server/Makefile branches/2016Q1/databases/postgresql92-client/Makefile branches/2016Q1/databases/postgresql92-server/Makefile branches/2016Q1/databases/postgresql93-client/Makefile branches/2016Q1/databases/postgresql94-client/Makefile |
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.