Hi Dan,
I'm not sure if I missed something in this thread. But wouldn't the
following suffice for the use case described?
If, as described, you want to continue using the installed version 15
instead of the current PostgreSQL version 17 on the box, this can be
achieved by setting the following line in /etc/make.conf:
DEFAULT_VERSIONS+= pgsql=15
This makes version 15 the default version for that box, which should
also be used by the port databases/p5-DBD-Pg (per USES=pgsql).
However, I don't have a box on which I can try this out :(
Regards,
Rainer
Am 20.05.25 um 11:30 schrieb Dan Mahoney (Ports):
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.
