php/composer: turn into meta package as 7.4 is EOL; php8.[01] and composer8.[01]: add alternatives groups.

[TinfoilSubmarine]

Should not be merged until PHP 7.4 EOL (28 Nov 2022): https://www.php.net/supported-versions.php

Testing the changes

• I tested the changes in this PR: YES

Packages depending on php:

• ampache ampache: update to 5.5.1. #38973
• composer (need to decide how to handle running with multiple PHP versions)
• phoronix-test-suite (verified to work with the php8.1 interpreter after symlinking /usr/bin/php8.1 to /usr/bin/php. Since it works with both, I don't think there is any change needed to the phoronix-test-suite package.)
• phpMyAdmin phpMyAdmin: update to 5.2.0, fix update check. #38984

Packages depending on php-gd:

• zabbix-frontend-php zabbix: update to 6.2.2. #38982

Packages depending on php-mysql:

• zabbix-frontend-php zabbix: update to 6.2.2. #38982

Packages with php-devel in *makedepends:

• libguestfs (configures and compiles fine with 8.1, but php is not enabled by default anyway)

Other things to take care of:

• php-pear

[paper42]

I think this is a bit too fragile and we should wait with this for php 7.4 EOL which should be in November. Which /usr/bin/php gets chosen when the user has php (7) and php8.0 installed? Are we sure it always works as expected and won't break the setup for some users who rely on /usr/bin/php being php7, etc?

[Chocimier]

It does not work correctly:

before:

composer --version
Composer version 2.2.4 2022-01-08 12:30:42

after:

composer --version
PHP 7.4.30 (cli) (built: Aug  9 2022 17:56:39) ( NTS )
Copyright (c) The PHP Group

composer -h       
Usage: php [options] [-f] <file> [--] [args...]

[TinfoilSubmarine]

It does not work correctly:

before:

composer --version
Composer version 2.2.4 2022-01-08 12:30:42

after:

composer --version
PHP 7.4.30 (cli) (built: Aug  9 2022 17:56:39) ( NTS )
Copyright (c) The PHP Group

composer -h       
Usage: php [options] [-f] <file> [--] [args...]

Should be fixed, I dropped the -f from /usr/bin/composer${_php_version}

[TinfoilSubmarine]

So, the one thing that I'm unsure of is for composer. Currently, there is a package for each PHP version with a shim script to invoke composer with the right interpreter:

void-packages/srcpkgs/composer8.0/files/composer8.0

Line 2 in b1800a9

php8.0 /usr/libexec/composer.phar8.0 "$@"

void-packages/srcpkgs/composer8.1/files/composer8.1

Line 2 in b1800a9

php8.1 /usr/libexec/composer.phar8.1 "$@"

This could also be handled by having a single composer package with the shim script, but call php which is handled by alternatives. But I think that may be confusing since it isn't as explicit.

[TinfoilSubmarine]

So, the one thing that I'm unsure of is for composer. Currently, there is a package for each PHP version with a shim script to invoke composer with the right interpreter:

void-packages/srcpkgs/composer8.0/files/composer8.0

Line 2 in b1800a9

php8.0 /usr/libexec/composer.phar8.0 "$@"

void-packages/srcpkgs/composer8.1/files/composer8.1

Line 2 in b1800a9

php8.1 /usr/libexec/composer.phar8.1 "$@"

This could also be handled by having a single composer package with the shim script, but call php which is handled by alternatives. But I think that may be confusing since it isn't as explicit.

After thinking about this, I think that it's best to keep the separate composer packages, since collapsing into one and relying on xbps-alternatives to choose a php version restricts the utility of having alternatives in the first place. If I want to have both a PHP 8.0 and 8.1 installation on a single machine, I would still like to be able to use composer with both 8.0 and 8.1.

[paper42]

I think it would be nice to make every package depend on a specific version that's the last supported one.

[TinfoilSubmarine]

Anything else needed for this? 7.4 is officially EOL now

[paper42]

I can imagine that people will be confused by these meta packages a bit - they will install php-fpm, enable the php8.1-fpm service and then on an update php will be updated to 8.2 and php-fpm will be orphaned and removed. Do you think we could somehow clarify that php-* packages will move in short_desc or even as a page in void-docs?

[TinfoilSubmarine]

I think something like that could be helpful. Probably want a page since it's fairly easy to miss a short_desc if you just do xi php-fpm. Reminds me of #38306

[TinfoilSubmarine]

OK, I opened void-linux/void-docs#731

[jchook]

@TinfoilSubmarine thank you very much my man. Very appreciative of this much-needed change! Also very educational to read the PR as well.