postgresql92, postgresql93, postgresql94, postgresql95, postgresql96, postgresql10: universal variant fails

[ryandesign (Ryan Carsten Schmidt)]

The postgresql92, postgresql93, postgresql94, postgresql95, postgresql96, postgresql10 ports fail to configure when the universal variant is used:

DEBUG: Executing proc-post-org.macports.configure-configure-0
DEBUG: system: cd /opt/local/var/macports/build/_Users_rschmidt_macports_macports-ports-svn-trunk_databases_postgresql10/postgresql10/work/postgresql-10.1/src/include  && ed - pg_config.h < /Users/rschmidt/macports/macports-ports-svn-trunk/databases/postgresql10/files/pg95_config.h.ed  && touch stamp-h
?
Command failed: cd /opt/local/var/macports/build/_Users_rschmidt_macports_macports-ports-svn-trunk_databases_postgresql10/postgresql10/work/postgresql-10.1/src/include  && ed - pg_config.h < /Users/rschmidt/macports/macports-ports-svn-trunk/databases/postgresql10/files/pg95_config.h.ed  && touch stamp-h
Exit code: 2

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

I would humbly suggest that using the ​muniversal PortGroup is the best long-term solution.
This is exactly the kind of situation the PortGroup was designed for.

Short-term, however, some changes would have to be made.
So far, I have only had a chance to look at ​postgresql96.
The main change is:

• Do not manually ​build and ​install contrib files.
• Instead, set build.target and destroot.target to world and install-world respectively.

The use of the ​contribs variable is problematic in the first place.
It is set in post-build and used in post-destroot.
If the build and destroot phases are performed separately, I believe certain files would not be installed (with no error).

Attached is my proposed solution for postgresql96.
However, I do not relish the idea of modifying and testing all six ports (postgresql92, postgresql93, postgresql94, postgresql95, postgresql96, and postgresql10) or even the older ports (postgresql7, postgresql80, postgresql81, postgresql82, postgresql83, postgresql84, postgresql90, and postgresql91).

Is there any way to mark some of these as obsolete?
Ideally, there would only be one PostgreSQL port.
I am not an expert on PostgreSQL, so I do not know if there are reasons for keeping so many versions around.
Perhaps only support the latest two or three versions?
Even limiting PostgreSQL to the ​five versions supported upstream would be helpful.

[ryandesign (Ryan Carsten Schmidt)]

I have verified that postgresql90 and postgresql91 build universal already so they're not affected by the problem I was reporting. However, I don't know if the changes you're proposing would be of benefit to them anyway.

Having a single postgresql port would not be ideal. Users need to be able to choose when and if they upgrade their database servers to a new version. MacPorts has always offered multiple versions of database servers.

[mf2k (Frank Schima)]

Replying to MarcusCalhoun-Lopez:

Even limiting PostgreSQL to the ​five versions supported upstream would be helpful.

I fully agree that we should only be supporting versions that are supported upstream. Security issues will not be addressed by the unmaintained versions.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In b40aad1b58f9cf542b856411cf656fe9414c8bb5/macports-ports:

postgresql*: don't build/install contrib files manually

Instead, set build.target and destroot.target
to world and install-world respectively.
This behavior seems to have been inherited from PostgreSQL 7 & 8,
where world and install-world were not available.

See #55303

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In ee3d4d532f67252919c2b7bd09ec47b5b30b3f37/macports-ports:

postgresql*: use muniversal PG

Fixes #55303