Hi
On 2026-07-20 20:13, Jakub Zelenka wrote:
On 2026-07-20 19:24, Jakub Zelenka wrote:
> I don't exactly understand why that Autoconf section does not mention
> that
> it is not available on distro levels for RHEL 8 and 9 so it makes
> things
> difficult for packagers like Remi who explicitly asked to delay it:
The proposal clearly specifies the minimum versions for various
distros.
Well but it's pretty confusing for voters because they don't know that
our
minimum target is RHEL 8 which we have been using for deciding about
minimum versions before. The fact that this even goes through RFC in
this
Depending on how you look at it, RHEL 8 is either already EOL or will
live until 2033. Halting all library upgrades for another 7 years is
neither in the interest of PHP users and maintainers.
form is not good because we should rather have a general policy about
minimum of supported distros that PHP is built on and set minimum deps
versions based on that. This just hides this fact and for voters that
have
no idea what the supported distro versions are as this is very hard to
notice.
As the RFC states, the autoconf requirement only *affects builds from
git*. The official releases from the PHP project include a ready-made
`./configure` script and thus do not require autoconf to build PHP. This
is similar to ext/uri and the uriparser dependency, where PHP bundles a
working version, but if you are unhappy with that, then you’ll need a
very recent version of the library that may not be provided on older
distros.
The question has been left unanswered. Since the only reply was a
vague
“I prefer to wait”, I proceeded with writing the RFC.
Well, that seems kind of clear to me that some possibility is there
otherwise there wouldn't be such preference.
From what I see and understand, the core RHEL 8 distribution only
provides PHP 7.2, any newer PHP version requires the use of external
repositories - or a custom build. If you don’t want to rely on the
PHP-provided `./configure` script, then autoconf 2.71 would similarly be
available in external repositories (EPEL).
I consider being able to properly rely on C11 functionality to be
worth
it. Generally speaking, compilers on operating systems that don’t have
autoconf 2.71 likely also don’t (fully) support C11, the lack of a
modern autoconf is really just a canary there.
Do you have some specific problems and why does it need to be enforced
just
before the feature freeze and cannot wait longer?
I have various pending PRs to clean up custom implementations for things
that are guaranteed by C11. But these naturally require that we actually
can rely on C11 in practice with proper checks rather than an
easy-to-miss note in the documentation.
With regard to the timing, it was just convenient to bundle the two
upgrades together and I relied on Eric to handle the RFC stuff. Given
that it's cleanup-only and the first Alphas have already been released,
I'd be okay with delaying the merge of the autoconf upgrade for (early)
PHP 8.7.
Best regards
Tim Düsterhus
