> On May 19, 2025, at 22:47, Mathieu Arnold <[email protected]> wrote:
> Well, you have three choices :
>
> - Upgrade your PostgreSQL server. Using packages means you upgrade
> everything all the time.
> - Build your own packages with the default PostgreSQL set to 15.
> - Do not upgrade.
>
> The FreeBSD packages system, and ports, is a "rolling release", you have
> to move with the flow.
>
> PostgreSQL major version changes have always been difficult, it is not
> new.
> Until someone (hint, it could be you) automates the upgrades, or allows
> multiple version installations by putting each in its own space, like
> it's done in other oses, put things in lib/postgresqlXX/{bin,lib},
> share/postgresqlXX, you will have to do so the upgrades manually, by
> following the instructions in UPDATING.
After drinking some coffee and looking over the porter's handbook,I believe
I've managed to flavor this port in my local copy -- by adding a bunch of
if-blocks for the various versions of postgres that simply set the USES= line
to the appropriate versions, like this.
FLAVORS= default pg13 pg14 pg15 pg16 pg17 pg18
FLAVOR?= ${FLAVORS:[1]}
pg13_PKGNAMESUFFIX= -pg13
pg14_PKGNAMESUFFIX= -pg14
pg15_PKGNAMESUFFIX= -pg15
pg16_PKGNAMESUFFIX= -pg16
pg17_PKGNAMESUFFIX= -pg17
pg18_PKGNAMESUFFIX= -pg18
.if ${FLAVOR} == default
USES= perl5 pgsql
.endif
.if ${FLAVOR} == pg13
USES= perl5 pgsql:13
.endif
.if ${FLAVOR} == pg14
USES= perl5 pgsql:14
...and so on.
It's a bit long, but that's only because we're supporting six(!!) versions of
postgres. (Seven, actually, but /usr/ports/Mk/Uses/pgsql.mk only lists
VALID_PGSQL_VER= 13 14 15 16 17 18)
There may be a more elegant way by extracting the string from the flavorname
and using it to set the requisite PG version versus a bunch of "ifs", and there
may be some kind of "switch" or "case" statement in these makefiles that I'm
not aware of. I'm not super versed in makefiile string-bashing. This is not a
large package, and I don't know if the ports tree has a magic syntax for "build
for many supported versions of a USES, but this would solve it. Extra build
time is also fairly minimal.
I can supply the full patch. Is it possible this could be accepted? If this
works, then the version of the perl db driver stays locked with whatever DB
you've installed, and because it's a flavor, it should cause things that
require this (for example, pgtop, which is a perl program) to work with any
version that you've installed versus forcing you onto the default version. It
would mean when perl gets upgraded, the new version comes in with its current
flavor (which it didn't previously because we had it locked, so it was still
sitting in the perl5.38 libs).
If you upgrade your version of postgres, the solver might or might not be able
to find you the corresponding flavored port, but if not, at least there would
be something in the repos that you could install, which is still better than
the situation now.
Thoughts?
-Dan
PS: You mention UPDATING. Is there planned to be a way to display that via pkg
to users who are affected but who do not have a ports tree checked out? That
would be useful.
