PostgreSQL: multilple versions and one client to depend on

[girgen]

Summary

Suggestion for how to simplify managing the different versions of PostgreSQL.

• Keep just one client, the latest.
• Each server version installs with its own version suffix in libexec/postgresqlNN (for binaries) and lib/postgresqlNN (for libraries)
• Use FLAVORS for server dependant ports (mostly server extensions)

[se]

I have added a number of inline comments. Version 10 files came first, so I added inline comments to them, but the comments should apply to all versions including the latest.

EoL of PostgreSQL-9.6 is 2021-11-11, i.e. within less than 1 week. A DEPRECATED notice should be added (but I'd keep the port available until the end of the year, unless it would hold back committing of the planned multiple version changes ...).
This will allow some simplifications, especially when the ports are converted to use FLAVORs.

BTW: The file "databases/postgresql14-server/files/502.pgsql.in" has been renamed to "502.postgresql14.in" and back to "502.pgsql.in" according to this review (I cannot at an inline comment for this issue, since these are only renames ...)

Mk/bsd.default-versions.mk

109

If we want to provide the latest client but be more conservative with server versions, I'd suggest to provide both PGSQL_SERVER_DEFAULT and PGSQL_CLIENT_DEFAULT.
The server could stay at 13 for a bit longer, and the client could be set to 14, for example.

databases/pg_stat_kcache/Makefile

13

Why 10 and not 10+ ???

databases/postgresql10-server/files/postgresql10.in

3

Is a PROVIDE: postgresql14 useful?

I had kept that name unversioned, since I do not expect other rc scripts to require some specific postgresql version.
And since we cannot require e.g. "postgresql13 or postgresql14", I doubt that any rc file will be able to depend on postgresql at all, if a versioned PROVIDE/REQUIRE identifier is used.

56

Simplify condition

56

Defining: profile_name="postgresql%%PG_SUFFIX%%_profiles"

would allow to reduce "${postgresql%%PG_SUFFIX%%_profiles}" to "${profile_name}" throughout the script.

68

Simplify condition

71

Use checkyesno from rc.subr?

databases/postgresql10-server/pkg-plist-contrib

1

The suggestion by bapt@ and also established practice is to use "bin/oid2name%%PG_SUFFIX%%".
Precedent can be seen in gcc, clang, ...

4

Instead of "lib/postgresql%%PG_SUFFIX%%" I'd define "%%PG_LIBDIR%%" to simpify the PLIST file ...
(And %%PG_BINDIR%% in the same way, independent of the decision where binaries are placed (libexec/postgresql vs. bin).

databases/postgresql14-server/Makefile

19

My review Simplify CONFLICTS definitions would lead to a much simpler CONFLICTS definition - I'm looking for reviewers that support that review (bapt has promised to have a look, but I'm still waiting to have it approved ...)

Besides: Is this really a build conflict, too. Else this should be changed to CONFLICTS_INSTALL. But with multiple installed versions, this may become moot, anyway.

336–337

I'd keep the name of the periodic script unversioned in the files directory (i.e. "files/502.postgresql") and only add the version suffix during installation:

	${INSTALL_SCRIPT} ${WRKDIR}/502.postgresql \
			${STAGEDIR}${PREFIX}/etc/periodic/daily/502.postgresql${PG_SUFFIX}

databases/postgresql14-server/pkg-plist-client

1178

If multiple client will be supported, this and the following man-page may cause conflicts.

[girgen]

Mk/bsd.default-versions.mk

109

Yeah, perhaps you're right, the move to 13 was just made, we should keep that for a while, I guess.

There should be a defined process for when to move to a new default version, IMO. Is not NN.1 enough? NN.2? That is six months after inital release... I think that is plenty of time. Maybe even NN.1 is enough?

databases/pg_stat_kcache/Makefile

13

Hmm, maybe I just tested something, this is of course fault. :-D it should be 10+

databases/postgresql10-server/files/postgresql10.in

3

I just checked if anything really does REQUIRE: postgresql. I first assumed not, bu I was wrong.

These are mostly client apps that really do require the database to be started first. I agree, keeping it at "postgresql" is more reasonable than crafting per server version. In fact, version specific PROVIDE is just wrong. Excellent, I'll remove it.

56

Simplify condition

Yeah, that better.

56

Defining: profile_name="postgresql%%PG_SUFFIX%%_profiles"

would allow to reduce "${postgresql%%PG_SUFFIX%%_profiles}" to "${profile_name}" throughout the script.

56

Defining: profile_name="postgresql%%PG_SUFFIX%%_profiles"

would allow to reduce "${postgresql%%PG_SUFFIX%%_profiles}" to "${profile_name}" throughout the script.

true. sounds like a good improvement.

databases/postgresql10-server/pkg-plist-contrib

1

The suggestion by bapt@ and also established practice is to use "bin/oid2name%%PG_SUFFIX%%".
Precedent can be seen in gcc, clang, ...

Ah, yes, I though about that too. I'll try it out. For daemons, I disagree that there is any proper practice at all, but perhaps this is still better.