Add Alpine 3.21 variant

[jnoordsij]

Modelled after #1514.

Requires docker-library/official-images#18024.

This PR adds a variant for Alpine 3.21 and drops the 3.19 variant at the same time.

See also https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.21.0.

[jnoordsij]

PHP 8.1 builds are failing on what looks to me an issue reported at php/php-src#15701. Not sure why it's only happening on 8.1 though...

[jnoordsij]

From php/php-src#15701 (comment):

It's quite likely that there had been relevant changes between PHP 8.1 and 8.2. But anyway, PHP-8.1 won't receive regular bugfixes anymore, so this is moot.

So given that it is unlikely PHP 8.1 will support gcc 14.2/work with Alpine 3.21, I've opted to exclude the combo, similar to the approach taken in #1348. Given that Alpine 3.20 EOL (2026-04-01) should be past PHP 8.1 EOL (2025-12-31), it should be fine keeping around this combination until then. When Alpine 3.22 lands, 3.20 can be kept around just for 8.1, similar to how it was done in #1405.

[tianon]

Thank you for your work/digging! ❤️

I have to say I'm not a huge fan of reintroducing the matrix complexity of #1348+#1405 😬 It created a lot of downstream pain also, and I'm not sure how/whether we can reasonably resolve that, so I'll probably just have to suck it up, but I'd like to let it simmer for a little bit first in case another possibility comes to mind / surfaces. 🙇 ❤️

[yosifkit]

I found php/php-src#11678 that looks related. Maybe there is a patch we could apply that is similar to the patch Alpine was using for 8.1: https://gitlab.alpinelinux.org/alpine/aports/-/blob/3.19-stable/community/php81/fix-lfs64.patch.

[yosifkit]

After adding the patch for php/php-src#11678, I found that php/php-src#14834 was needed or pecl failed to be installed by pear, so I ended up with this:

# add `patch` and `patchutils` packages to the apk install

# https://github.com/php/php-src/issues/11678
curl -fL 'https://github.com/php/php-src/commit/577b8ae4226368e66fee7a9b5c58f9e2428372fc.patch' -o 11678.patch; \
patch -p1 < 11678.patch; \
rm 11678.patch; \
# https://github.com/php/php-src/issues/14834
curl -fL 'https://github.com/php/php-src/commit/67259e451d5d58b4842776c5696a66d74e157609.patch' -o 14834.patch; \
filterdiff -x '*/NEWS' 14834.patch | patch -p1; \
rm 14834.patch; \

It succeeded building, but I think that there are likely hidden problems like in this output (especially given that the second patch was because of libxml upstream changes): Never mind, this warning shows up on PHP 8.4, so maybe those two patches are enough. Should we add them?

+ pecl update-channels
Updating channel "doc.php.net"
Error: Unable to create XML parser
Invalid channel.xml file
Updating channel "pear.php.net"
Update of Channel "pear.php.net" succeeded
Updating channel "pecl.php.net"
Update of Channel "pecl.php.net" succeeded

[jnoordsij]

Should we add them?

I like that a lot more; especially given that Alpine also took that approach themselves (see https://gitlab.alpinelinux.org/alpine/aports/-/blob/3.19-stable/community/php81/fix-lfs64.patch?ref_type=heads).

I've gone ahead and applied your suggestion. Currently I've opted to apply it also to PHP 8.1 + Alpine 3.20 where it is not strictly necessary, but I can't see it hurting in any way and this also ensures that a next Alpine update will not require further meddling with templates for this (and is more consistent).

A follow-up might be removing the -D_LARGEFILE_SOURCE from Alpine builds at some point, given that musl ignores it anyways (php/php-src#11678 pointed me to https://wiki.musl-libc.org/faq#Q:-Do-I-need-to-define-%3Ccode%3E_LARGEFILE64_SOURCE%3C/code%3E-to-get-64bit-%3Ccode%3Eoff_t%3C/code%3E), but it doesn't seem to hurt either.

[tianon]

Let's ship it ❤️