Thread: minimum Meson version

meson.build currently says

# We want < 0.56 for python 3.5 compatibility on old platforms. EPEL for
# RHEL 7 has 0.55. < 0.54 would require replacing some uses of the fs
# module, < 0.53 all uses of fs. So far there's no need to go to >=0.56.
meson_version: '>=0.54',

Since the current minimum supported Python version is now actually 3.6, 
we could update this a bit.

The first Meson version to require Python 3.7 is 0.62, so we should stay 
below that.

Moving to 0.55 and 0.56 would get rid of some future-deprecated warnings.

There is some conditional code for 0.57 and 0.59, so landing on either 
of these would allow getting rid of some of that.

I see that Rocky Linux 8 ships with Meson 0.58.2 [0], so maybe that is a 
good target to aim for.  (I don't know if that carried over from RHEL 8 
or is their own doing.)  But there aren't any compelling features new in 
0.58 (format strings seem nice but are pretty much cosmetic), so maybe 
setting the minimum to 0.57 is enough.

[0]: https://dl.rockylinux.org/pub/rocky/8/Devel/x86_64/os/Packages/m/

Peter Eisentraut <peter@eisentraut.org> writes:
> I see that Rocky Linux 8 ships with Meson 0.58.2 [0], so maybe that is a
> good target to aim for.  (I don't know if that carried over from RHEL 8
> or is their own doing.)  But there aren't any compelling features new in
> 0.58 (format strings seem nice but are pretty much cosmetic), so maybe
> setting the minimum to 0.57 is enough.

RHEL 8 does include meson 0.58.2.  However, it also ships ninja 1.8.2
which is too old:

$ meson setup build
...
Found ninja-1.8.2 at /usr/bin/ninja
ninja: error: build.ninja:7378: multiple outputs aren't (yet?) supported by depslog; bring this up on the mailing list
ifit affects you 

WARNING: Could not create compilation database.

So in the Red Hat universe, the first release that has usable meson
infrastructure for our purposes is RHEL 9, which has meson 0.63.3
and ninja 1.10.2.  Not sure how that factors into this calculation.
But unless we can back off our minimum ninja version, it's going
to be a long time before we can abandon the makefiles.

            regards, tom lane

Andres Freund <andres@anarazel.de> writes:
> On 2025-06-17 13:48:33 -0400, Tom Lane wrote:
>> RHEL 8 does include meson 0.58.2.  However, it also ships ninja 1.8.2
>> which is too old:

> IIRC we discussed this before, in some other thread. We could make that work,
> but at the time we didn't consider it worth working on.

Yeah, we've definitely been over that before.  I think at the time
we were still in the mode of "get meson to work at all", and so it
didn't seem high priority.  But it's the sort of cleanup we need
to start thinking about if we want meson to be our only build system.

> From my POV, which I am sure is not uniformly shared, we don't need to support
> new major PG versions on things like RHEL 8. After all full support for RHEL 8
> has ended a year ago.

Nope, I don't share that opinion.  RHEL 8 will be a perfectly usable
platform at least through 2029 (when maintenance support will stop,
according to wikipedia).  And LTS platforms like that are our bread
and butter for real-world use.

            regards, tom lane

Hi,

On 6/17/25 2:23 PM, Andres Freund wrote:
> After all full support for RHEL 8 has ended a year ago.
> 

Yes, full support ended May 31, 2024 - but extended support ends May 31, 
2029.

Devrim, feedback ?

Best regards,
  Jesper

On Tue, 17 Jun 2025 at 22:19, Andres Freund <andres@anarazel.de> wrote:
> Please do note that I was not suggesting removing support for it from minor
> versions and that the earliest we, IMO, would conceivably remove autoconf
> support would be PG 20.
>
> I'm sure there will be some folks desperate to run PG 20 on RHEL 8, ~3 years
> after main support ended, 2 years before end of maintenance support, but it
> won't be that many. And for those it still wouldn't be hard, they'd need to
> install some up2date dependencies, but that's the price for doing something
> that's a really really bad practice.

+many. I really don't understand why we go so far out of our way to
support compiling and running tests with a completely unmodified
ancient RHEL system.

I'm not saying we shouldn't support compiling Postgres on these
systems. But having Postgres compile with just the default system
packages seems an unreasonably high bar. People running ancient
systems like this should be comfortable enough with getting some more
recent build dependencies. Recent meson and ninja executables are just
a "pip install" away, even on RHEL8.

On 17.06.25 23:10, Jelte Fennema-Nio wrote:
> I'm not saying we shouldn't support compiling Postgres on these
> systems. But having Postgres compile with just the default system
> packages seems an unreasonably high bar. People running ancient
> systems like this should be comfortable enough with getting some more
> recent build dependencies. Recent meson and ninja executables are just
> a "pip install" away, even on RHEL8.

That's probably ok for developers, but then again, probably no one 
develops PostgreSQL master on RHEL 8.  But production RPM builds need to 
be done "in system", with the build tools being provided by 
vendor-supplied RPMs themselves, with all the signatures, attestations, 
and all that stuff that comes with it nowadays.

On Wed, 18 Jun 2025 at 07:38, Peter Eisentraut <peter@eisentraut.org> wrote:
> That's probably ok for developers, but then again, probably no one
> develops PostgreSQL master on RHEL 8.  But production RPM builds need to
> be done "in system", with the build tools being provided by
> vendor-supplied RPMs themselves, with all the signatures, attestations,
> and all that stuff that comes with it nowadays.

Okay, so maybe pip install is not what they want. But they could still
create a recent ninja & meson RPM themselves right. I assume they know
how to do that, because they'd need to do the same for PostgreSQL too
if they care about all the things you mentioned.

And what I just don't understand about this whole discussion: We're
talking about people who want to be frozen in time for 5 years
straight during this "maintenance support" window by the vendor (whom
they are paying), with only access to security fixes. But somehow they
do want to run the latest Postgres Major release, even though the one
that they had running still receives bug fixes and security fixes. I
just don't understand who these people are. Why do they care about
having no changes to their system to avoid breakage as much as
possible, except for their piece of primary database software, of
which they're happily running the bleeding edge.

Hi,

On 2025-06-18 12:27:44 -0400, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Wed, Jun 18, 2025 at 9:35 AM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> >> And what I just don't understand about this whole discussion:
> 
> > What I just don't understand about this discussion is a bunch of smart
> > people thinking that a bunch of other smart people have completely
> > lost their minds, while the second group thinks exactly the same about
> > the first group. There's hardly a topic to be found that produces more
> > apparent acrimony around here than what releases of things we ought to
> > still be supporting.
> 
> Indeed.  I think the compromise we've usually settled on is "we'll
> support release X as long as there's somebody willing to do the work".
> If it's not costing you personally any effort, why object to someone
> else wanting to spend effort on such things?

I don't think that's what we settled on *at all*, we rather settled on the
polar opposite.

Anyone that does work that is affected by support for old operating systems
has to either spend tremenduous energy arguing that we should remove support
for $old_os or spend tremenduous energy inventing workaround for $old_os.

I.e. folks demanding continued support for old operating systems do very
little work, whereas the folks that actually are affected a lot of time.  It's
*tremendously* demotivating.

For some recent examples take this thread or the discussion about removing
support for old openssl versions. How can either of those be described as
folks wanting to support old operating systems doing work?

Greetings,

Andres Freund

On Wed, Jun 18, 2025 at 6:27 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Indeed.  I think the compromise we've usually settled on is "we'll
> support release X as long as there's somebody willing to do the work".
> If it's not costing you personally any effort, why object to someone
> else wanting to spend effort on such things?

I don't think this is really the issue. It's usually - as here - about
what we could clean up or simplify by removing support for old
versions, as against the inconvenience caused to people who still want
to use those old versions. So it's often the people who are
volunteering to do the work want to break things for the people who
aren't doing anything except objecting to the breakage.

But it seems impossible to have rational discussions about this,
because - if I may exaggerate slightly for effect - some of us think
everyone with half a brain should upgrade within a week or two when a
new version comes out, while others of us think that there might be
someone out there who still has a working PDP-11. Since any policy
that anyone is likely to actually propose falls somewhere between
those two extremes, half of us are then bitterly unhappy with it.

--
Robert Haas
EDB: http://www.enterprisedb.com

Hi,

On 2025-06-18 13:20:54 -0400, Jesper Pedersen wrote:
> On 6/18/25 1:07 PM, Robert Haas wrote:
> > Since any policy
> > that anyone is likely to actually propose falls somewhere between
> > those two extremes, half of us are then bitterly unhappy with it.
> > 
> 
> Which is why I tried to add Devrim to the thread.
> 
> What builds on yum.postgresql.org are using meson ? If none of the RHEL 8
> ones are then the minimum requirements for ninja and meson can be bumped to
> the minimum versions to the ones that are.

The context of the discussion is removing autoconf based builds eventually (in
some future major version). For that it doesn't really matter whether yum.pg.o
currently uses meson.

Greetings,

Andres Freund

Andres Freund <andres@anarazel.de> writes:
> I think we should have a policy roughly along these lines:

> 1) We don't remove support for OS versions unless they block something

> 2) We don't remove support for OS versions in minor releases

> 3) If support for an old OS version makes something harder, it can be removed,
>    if and only if the OS is older than $age_criteria.

> 4) As an alternative to removing OS support via 3), somebody desiring
>    continued support for an older OS version can instead do the work to
>    develop an alternative to removal of support within $reasonable_timeframe

This seems like a reasonable policy skeleton.  As for $age_criteria,
I'd personally be satisfied with your option (e), which I'd rephrase
slightly as

  If the expected PG major version release date is after the end of
  maintenance support for an LTS distribution, that OS version does
  not need to be supported.

Given your rule (2), we'd still be on the hook to maintain back-branch
support for an EOL'd OS for five years, so I don't think that we need
to make the master-branch $age_criteria account for "extended
lifecycle".

In the context of RHEL, it says here [1] that RHEL8 maintenance
support runs through May 2029 while extended support runs through
May 2031.  That would still mean we're supporting RHEL8 for another
four years.  I'm not sure what the corresponding dates are for
other LTS vendors.

            regards, tom lane

[1] https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Product_life_cycle

I wrote:
> In the context of RHEL, it says here [1] that RHEL8 maintenance
> support runs through May 2029 while extended support runs through
> May 2031.  That would still mean we're supporting RHEL8 for another
> four years.  I'm not sure what the corresponding dates are for
> other LTS vendors.

I checked Debian and SUSE and noted that their "extended support"
windows are a lot shorter than RHEL's, just two or three years.
So maybe we shouldn't buy into RHEL's five-year window.  I do take
Jelte's point that it's unlikely somebody wants to run a bleeding-edge
PG release on a platform that's many years out from end of full
support; if they are using such a platform they probably prize
stability above all else.

Maybe we could compromise on

  If the expected PG major version release date is more than N years
  after the end of full support for an LTS distribution, that OS
  version does not need to be supported.

Defining it relative to "full support" also reduces questions about
whether extended support means the same thing to every LTS vendor.

If we set N=2 then we could drop RHEL8 support in PG 19; if we
set N=3 then it'd be PG 20 (measuring from end of full support
in May 2024).  I'd be okay with either outcome.

            regards, tom lane

Hi,

On Wed, 18 Jun 2025 at 11:58, Peter Eisentraut <peter@eisentraut.org> wrote:
>
> On 17.06.25 19:36, Peter Eisentraut wrote:
> > meson.build currently says
> >
> > # We want < 0.56 for python 3.5 compatibility on old platforms. EPEL for
> > # RHEL 7 has 0.55. < 0.54 would require replacing some uses of the fs
> > # module, < 0.53 all uses of fs. So far there's no need to go to >=0.56.
> > meson_version: '>=0.54',
> >
> > Since the current minimum supported Python version is now actually 3.6,
> > we could update this a bit.
> >
> > The first Meson version to require Python 3.7 is 0.62, so we should stay
> > below that.
> >
> > Moving to 0.55 and 0.56 would get rid of some future-deprecated warnings.
> >
> > There is some conditional code for 0.57 and 0.59, so landing on either
> > of these would allow getting rid of some of that.
> >
> > I see that Rocky Linux 8 ships with Meson 0.58.2 [0], so maybe that is a
> > good target to aim for.  (I don't know if that carried over from RHEL 8
> > or is their own doing.)  But there aren't any compelling features new in
> > 0.58 (format strings seem nice but are pretty much cosmetic), so maybe
> > setting the minimum to 0.57 is enough.
>
> Ok, let's make a small start.  Here is a patch set that moves the
> requirement to >=0.57.  As explained above, this allows getting rid of a
> bunch of conditional code and the future-deprecated warnings.

Thanks for the patches! I didn't check them yet but I encountered some
errors while using meson 0.57.0 and 0.57.1 but 0.56.2, 0.57.2 and
0.58.0 worked successfully. These errors seem to be related to these
specific minor versions, but I just wanted to mention them:

- meson install command fails on 0.57.0:

FAILED: src/interfaces/ecpg/preproc/preproc.y
/usr/bin/perl ../../postgres/src/interfaces/ecpg/preproc/parse.pl
--srcdir @CURRENT_SOURCE_DIR@ --parser
../../postgres/src/interfaces/ecpg/preproc/../../../backend/parser/gram.y
--output src/interfaces/ecpg/preproc/preproc.y
Died at ../../postgres/src/interfaces/ecpg/preproc/parse.pl line 698.

- meson test command fails on 0.57.1:

Exception in callback TestHarness._run_tests.<locals>.test_done() at
/home/nbyavuz/Desktop/projects/meson/meson/mesonbuild/mtest.py:1807
handle: <Handle TestHarness._run_tests.<locals>.test_done() at
/home/nbyavuz/Desktop/projects/meson/meson/mesonbuild/mtest.py:1807>
Traceback (most recent call last):
  File "/usr/lib/python3.13/asyncio/events.py", line 89, in _run
    self._context.run(self._callback, *self._args)
    ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/nbyavuz/Desktop/projects/meson/meson/mesonbuild/mtest.py",
line 1809, in test_done
    f.result()
    ~~~~~~~~^^
  File "/home/nbyavuz/Desktop/projects/meson/meson/mesonbuild/mtest.py",
line 1804, in run_test
    res = await test.run(self)
          ^^^^^^^^^^^^^^^^^^^^
  File "/home/nbyavuz/Desktop/projects/meson/meson/mesonbuild/mtest.py",
line 1350, in run
    await self._run_cmd(harness, cmd)
  File "/home/nbyavuz/Desktop/projects/meson/meson/mesonbuild/mtest.py",
line 1416, in _run_cmd
    returncode, result, additional_error = await p.wait(self.runobj.timeout)
                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/nbyavuz/Desktop/projects/meson/meson/mesonbuild/mtest.py",
line 1242, in wait
    await try_wait_one(p.wait(), timeout=timeout)
  File "/home/nbyavuz/Desktop/projects/meson/meson/mesonbuild/mtest.py",
line 1133, in try_wait_one
    await asyncio.wait(awaitables,
                       timeout=timeout, return_when=asyncio.FIRST_COMPLETED)
  File "/usr/lib/python3.13/asyncio/tasks.py", line 448, in wait
    raise TypeError("Passing coroutines is forbidden, use tasks explicitly.")
TypeError: Passing coroutines is forbidden, use tasks explicitly.
/usr/lib/python3.13/asyncio/events.py:89: RuntimeWarning: coroutine
'Process.wait' was never awaited
  self._context.run(self._callback, *self._args)
RuntimeWarning: Enable tracemalloc to get the object allocation traceback

--
Regards,
Nazir Bilal Yavuz
Microsoft

On 19.06.25 08:40, Nazir Bilal Yavuz wrote:
> Thanks for the patches! I didn't check them yet but I encountered some
> errors while using meson 0.57.0 and 0.57.1 but 0.56.2, 0.57.2 and
> 0.58.0 worked successfully. These errors seem to be related to these
> specific minor versions,

I think it's okay to expect that users use the latest patch version of a 
particular version.  So we don't need to concern ourselves with this 
particular problem.