void-linux
php/php8.0/php8.1 and composer/composer8.0/composer8.1: add alternatives groups.
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?
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...]
It does not work correctly:
before:
composer --version Composer version 2.2.4 2022-01-08 12:30:42after:
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}
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: https://github.com/void-linux/void-packages/blob/b1800a91d5d6054e6981eccdfdde0979d059448b/srcpkgs/composer8.0/files/composer8.0#L2 https://github.com/void-linux/void-packages/blob/b1800a91d5d6054e6981eccdfdde0979d059448b/srcpkgs/composer8.1/files/composer8.1#L2
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.
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:
https://github.com/void-linux/void-packages/blob/b1800a91d5d6054e6981eccdfdde0979d059448b/srcpkgs/composer8.0/files/composer8.0#L2
https://github.com/void-linux/void-packages/blob/b1800a91d5d6054e6981eccdfdde0979d059448b/srcpkgs/composer8.1/files/composer8.1#L2
This could also be handled by having a single composer package with the shim script, but call
phpwhich 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.
I think it would be nice to make every package depend on a specific version that's the last supported one.
@TinfoilSubmarine thank you very much my man. Very appreciative of this much-needed change! Also very educational to read the PR as well.
