Re: p5-dbd-pg

From: Stefan Esser <se_at_FreeBSD.org>
Date: Thu, 20 Jan 2022 15:23:15 UTC
Am 20.01.22 um 14:01 schrieb Dan Mahoney:
> 
> 
>> On Jan 20, 2022, at 3:54 AM, Kurt Jaeger <pi@freebsd.org> wrote:
>>
>> Hello,
>>
>> [postgres flavors]
>>> This feels like the ideal kind of port that could be flavored so
>>> it works with any installed postgres version.  I'm willing to submit
>>> patches, how hard would it be?
>>
>> If it needs to interoperate with php flavors (which it probably
>> does), it's probably a high level of complexity. But frankly,
>> that's only my guess, and I have not that much experience with flavors.
> 
> I don't think the perl database module needs to interoperate with the php flavors.  The problem is that p5-dbd-pg forced the upgrade to postgresql13-client.  There are no php modules on this box.
> 
>>> Is there a section in the porter's handbook that covers this?
>>
>> Yes:
>>
>> https://docs.freebsd.org/en/books/porters-handbook/flavors/
> 
> Seems straightforward enough, like the resulting packages would be p5-dbd-pg-postgres13 or something?

Work had started to make the postgresql-server ports co-exist
(which is quite a different issue from making them flavored)
late last year.

I have been busy with other parts of the system (BIT_SET and
CPU_SET changes for better ports compatibility and CONFLICTS
fixes) which had priority during the last weeks, but I plan
to return to fixing the postgresql ports issue (together with
girgen@ (Palle Girgensen) who had started working on fixing
these issues independently of me.

The goal is to have the latest PostgreSQL client port being
depended on by all server ports (since the client offers far
reaching backwards compatibility), and to have the servers
install their files in versioned directories to avoid conflicts
between them.

Other ports that depend on the client will then always depend
on the latest client version and they will work with all server
versions.

A conversion to FLAVORs might come at a later time, but it is
orthogonal to being able to support multiple servers and to
have the client independent from the server (just not at a
lower version than any supported server).

And the client version should not be coupled to the server
version at all (but old clients should still be available for
testing and in the unlikely case that backwards compatibility
does not work as documented in some edge case).

Regards, STefan