Re: minimum Meson version

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Greg Sabino Mullane <htamfids(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: minimum Meson version
Date: 2025-06-18 20:21:30
Message-ID: 1176150.1750278090@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
> On 18.06.25 19:53, Andres Freund wrote:
>> 1) We don't remove support for OS versions unless they block something

> Maybe it's worth clarifying the interpretation of this.

> For example, for the purpose of this thread, I wouldn't consider RHEL8
> to be blocking anything at the moment. It's technically blocking moving
> the meson requirement past some version, but that in turn isn't really
> blocking anything.

It's not the meson version that's the problem with RHEL8, it's the
ninja version, which is blocking our *use* of meson (and therefore
blocking removal of autoconf).

> (Also, they sometimes ship updated python or openssl versions, for
> example, so there is also a possible difference between support in its
> original version, support with updates, and no support at all.)

Right. I think it's fair to say that we'll support only fully-updated
installations.

> (I initially thought that RHEL8 was a typo for RHEL7, because we still
> support RHEL7!! We should drop that first!)

As per Andres' proposed rule 1, we won't drop support for an old
version until it's blocking some change we want to make. In this
context it wouldn't surprise me a bit if we end up dropping RHEL7
and RHEL8 at the same time and for the same reason (ie, lack of
new-enough meson/ninja packages).

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Treat 2025-06-18 20:57:55 Re: pg_dump/pg_dumpall help synopses and terminology
Previous Message Christoph Berg 2025-06-18 20:09:01 Re: CHECKPOINT unlogged data