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