Arch Linux

The runtime directory should be named after the name of the package (php-legacy-fpm), so this is a packaging bug.

You are right this is quite inconsistent. The PHP convention which always adds the suffix at the end and not after "php". The latter results in a binary called /usr/bin/php-fpm-legacy. (We were already inconsistent with php7)

I guess there are two options
* Follow our php-legacy-* naming scheme and rename binaries and config if needed
* Follow PHP's naming scheme, rename all the packages and always add "-legacy" to the end: php-fpm-legacy, php-gd-legacy.

This should affect binaries in php-legacy-fpm and php-legacy-cgi.

Any preferences? I tend towards solutions #1 as I find it less confusing; but I'd go with either.

I guess my vote doesn't count much as I'm not a member of the Arch bunch - not even a Trusted User. However, I had lots of 'fun' lately migrating my own Nextcloud installation from php to php-legacy, documenting the required steps in Nextcloud's wiki article, updating the wiki article in general and supporting several others with the migration. Going from php-legacy-fpm to php-fpm-legacy and similar changes all over Arch's PHP would cause another round of trouble that I (honestly) would like to avoid. So I vote for option #1.

@pierre: I'd also choose option one, but I also have zero idea what/if it'll break consumers (guess we'll need to adapt service files etc. for php-legacy-fpm too).

A quick and dirty search in all php-legacy-* packages revealed:

Inconsistent file names:

php-legacy-8.1.14-3-x86_64: usr/share/man/man1/php-config-legacy.1.gz
php-legacy-8.1.14-3-x86_64: usr/bin/php-config-legacy
php-legacy-cgi-8.1.14-3-x86_64: usr/share/man/man1/php-cgi-legacy.1.gz
php-legacy-cgi-8.1.14-3-x86_64: usr/bin/php-cgi-legacy
php-legacy-fpm-8.1.14-3-x86_64: usr/share/man/man8/php-fpm-legacy.8.gz
php-legacy-fpm-8.1.14-3-x86_64: usr/bin/php-fpm-legacy

Inconsistent content (binary files excluded):

php-legacy-fpm-8.1.14-3-x86_64: etc/php-legacy/php-fpm.conf: ;pid = /run/php-fpm-legacy/php-fpm.pid
php-legacy-fpm-8.1.14-3-x86_64: etc/php-legacy/php-fpm.d/www.conf: listen = /run/php-fpm-legacy/php-fpm.sock
php-legacy-fpm-8.1.14-3-x86_64: usr/lib/tmpfiles.d/php-legacy-fpm.conf: d /run/php-fpm-legacy 755 root root
php-legacy-fpm-8.1.14-3-x86_64: usr/lib/systemd/system/php-legacy-fpm.service: PIDFile=/run/php-fpm-legacy/php-fpm.pid
php-legacy-fpm-8.1.14-3-x86_64: usr/lib/systemd/system/php-legacy-fpm.service: ExecStart=/usr/bin/php-fpm-legacy --nodaemonize --fpm-config /etc/php-legacy/php-fpm.conf
php-legacy-8.1.14-3-x86_64: usr/lib/php-legacy/build/phpize.m4: [php-config-legacy],

No that much - IMHO.

After having a closer look I might reverse my opinion :-)

What I was going for was replacing all occurrences of php with php-legacy. ./configure even seems to have an option to accomplish this "--program-transform-name='s/php/php-legacy/'". Even though this is advertised, it sadly does not work: https://github.com/php/php-src/pull/3996

Binaries like phpize or phar are good examples where this approach would fail and is probably one of the reasons why the PHP devs settled with a simple suffix.

With 8.1.14-4 I matched the service name to the binary.

I have check packages for Alpine and Debian/Ubuntu. They are all consistently inconsistent in the same way: The package php-$suffix-fpm contains the binary php-fpm-$suffix.

@Pierre Schmitz: What is the conclusion now? Everything will remain as is? What will happen to the service files

/usr/lib/systemd/system/php-fpm-legacy.service
/usr/lib/systemd/system/php-legacy-fpm.service -> php-fpm-legacy.service

Yes, with the latest changes the setup is reasonable consistent and especially in line with what other distros are doing.

I added the symlink to not break installs made with the privious package.