Remove PHP 8.0

[jnoordsij]

Based on #1349.

PHP 8.0 will reach EOL on November 26 2023 (see https://www.php.net/supported-versions.php).
This PR removes the 8.0-based images and aliases.

It also drops the PHP 8.1 Alpine 3.16 variant, that was temporarily added in #1412, but should be obsolete now that Nextcloud 25 is EOL. (Which returns the versions.sh script finally back to a more clean state ;) ).

It is probably unwanted to merge this before November 26nd and before any final confirmation, hence the draft state.
However, given no activity on the 8.0 branch since August (see https://github.com/php/php-src/commits/PHP-8.0), one may expect a last-minute release seems unlikely.

[jnoordsij]

Rebased onto #1464, that should be merged first.

Note that NextCloud 25 has now been dropped; see also nextcloud/docker#2102.

[jnoordsij]

Looking at https://fosstodon.org/@php/111483350076351502 it looks EOL is official.

[PhrozenByte]

It also drops the PHP 8.1 Alpine 3.16 variant, that was temporarily added in #1412, but should be obsolete now that Nextcloud 25 is EOL. (Which returns the versions.sh script finally back to a more clean state ;) ).

Can we keep the Alpine 3.16 variant for PHP 8.1 (till EOL of PHP 8.1, i.e. for about one more year)? The underlying issue that PHP 8.1 won't work with OpenSSL 3 as of Alpine 3.17 and 3.18 persists. Nextcloud isn't the only affected app by this, it's any app that still uses PHP 8.1 and requires OpenSSL. An example is LimeSurvey: it officially only supports up to PHP 8.1 (see manual, "LS 6.x from PHP 7.4.x to 8.1.x"), and requires OpenSSL ("The following PHP modules/libraries should be enabled: […] openssl").

[jnoordsij]

It also drops the PHP 8.1 Alpine 3.16 variant, that was temporarily added in #1412, but should be obsolete now that Nextcloud 25 is EOL. (Which returns the versions.sh script finally back to a more clean state ;) ).

Can we keep the Alpine 3.16 variant for PHP 8.1 (till EOL of PHP 8.1, i.e. for about one more year)? The underlying issue that PHP 8.1 won't work with OpenSSL 3 as of Alpine 3.17 and 3.18 persists. Nextcloud isn't the only affected app by this, it's any app that still uses PHP 8.1 and requires OpenSSL. An example is LimeSurvey: it officially only supports up to PHP 8.1 (see manual, "LS 6.x from PHP 7.4.x to 8.1.x"), and requires OpenSSL ("The following PHP modules/libraries should be enabled: […] openssl").

Do you have any example of things actually breaking with the PHP 8.1 Alpine 3.17/3.18 images? That might help in sorting out if an Alpine 3.16 variant is still required. (Also that might be something worth reporting upstream, given that OpenSSL 1.1.1 has reached EOL).

As actually PHP 8.1 does work with OpenSSL 3 (see also https://www.php.net/manual/en/openssl.requirements.php), that's why it was not given special treatment when introducing the Alpine 3.17 variant (see also #1348) and is still built perfectly fine with OpenSSL 3 as of today. I'm not sure why exactly the Nextcloud build was failing, but I'd assume that was through some direct dependency on OpenSSL 1.1 related functions/calls, because as said there should be no generic issue with OpenSSL 3 + PHP 8.1.

[jdreesen]

It doesn't work for us with Alpine 3.17+ / OpenSSL 3 because Alpine no longer delivers it with Blowfish.

So something like openssl_encrypt($data, 'BF-ECB', $secretKey, OPENSSL_RAW_DATA | OPENSSL_ZERO_PADDING); fails.

[PhrozenByte]

Do you have any example of things actually breaking with the PHP 8.1 Alpine 3.17/3.18 images? That might help in sorting out if an Alpine 3.16 variant is still required.

I was just about to write a report about the issue with my LimeSurvey container and explaining what's going on, but in the course of creating a proper reproducer I noticed that my issue simply was that there was an implicit dependency to openssl-dev with Alpine 3.16, but not with Alpine 3.18. I just made the openssl-dev dependency explicit and yeah, it works now 🙈

Happens if one just assumes but never actually verifies that it is the same issue as for Nextcloud 🙈

Sorry for the noise, thank you very much for taking it into consideration @jnoordsij!

Original post, the following can be ignored...

To start off with, I'm no expert in building sources, I'm one of these people that happily use Linux repositories and never ask questions about it 😄 So this might indeed be something one can easily fix. Thanks for taking it into consideration @​jnoordsij!

I've created a LimeSurvey container (which ultimately bases on php:8.1-fpm-alpine) that needs to install the imap extension with SSL support enabled. As I said, I don't really know what's going on when building sources, but since you just said that PHP 8.1 supports OpenSSL 3, it might not actually be an issue with OpenSSL 3, but maybe with the IMAP extension instead (or the combination of the two). I don't know whether Nextcloud 25 had the same issue (probably not, they don't install the IMAP extension), or something else (I searched for it, but couldn't find any reasoning; maybe @​J0WI can add some insights about what the issue was for Nextcloud 25?). Anyhow, building the IMAP extension for PHP 8.1 on Alpine 3.17/3.18 always fails with the following error blaming OpenSSL (also see this build, step "Build container image", starting at line 236; the openssl package comes pre-installed by the php base container):

# docker-php-ext-configure imap --with-imap-ssl
Configuring for:
PHP Api Version:         20210902
Zend Module Api No:      20210902
Zend Extension Api No:   420210902
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for a sed that does not truncate output... /bin/sed
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for cc... cc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether cc accepts -g... yes
checking for cc option to enable C11 features... none needed
checking how to run the C preprocessor... cc -E
checking for icc... no
checking for suncc... no
checking for system library directory... lib
checking if compiler supports -Wl,-rpath,... yes
checking build system type... x86_64-pc-linux-musl
checking host system type... x86_64-pc-linux-musl
checking target system type... x86_64-pc-linux-musl
checking for PHP prefix... /usr/local
checking for PHP includes... -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend -I/usr/local/include/php/ext -I/usr/local/include/php/ext/date/lib
checking for PHP extension directory... /usr/local/lib/php/extensions/no-debug-non-zts-20210902
checking for PHP installed headers prefix... /usr/local/include/php
checking if debug is enabled... no
checking if zts is enabled... no
checking for gawk... no
checking for nawk... no
checking for awk... awk
checking if awk is broken... no
checking for IMAP support... yes, shared
checking for IMAP Kerberos support... no
checking for IMAP SSL support... yes
checking for utf8_mime2text signature... new
checking for U8T_DECOMPOSE... yes
checking for pam_start in -lpam... no
checking for crypt in -lcrypt... yes
checking for openssl >= 1.0.2... no
configure: error: Package requirements (openssl >= 1.0.2) were not met:

Package 'openssl', required by 'virtual:world', not found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables OPENSSL_CFLAGS
and OPENSSL_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

Here's a proper reproducer with upstream php:8.1-fpm-alpine3.16 (I'm using Podman, I've never used Docker, but I assume one can simply replace podman by docker and it should work as well):

$ podman run -it docker.io/php:8.1-fpm-alpine3.18 ash
# apk add --virtual .php-build-deps imap-dev
[… irrelevant …]
# docker-php-ext-configure imap --with-imap-ssl
[… same as above …]

All works just fine with PHP 8.1 on Alpine 3.16.

[tianon]

As usual, thank you for your thoroughness, @jnoordsij! 🙇