In D26848#599940, @ale wrote:

The main question is if it is really needed at all. I never saw a use-case for the zts/debug handling. While i can understand the idea you explained, it looks like these cases will only occur when building the code by yourself AND switching such basic options afterward. And i think with pkg becoming the main source of installation this scenarios are even more unlikely. So i personally would try to remove it all, but the last attempt failed badly :D

I'm not sure what you mean with "I never saw a use-case for zts handling". If you are using a threaded SAPI (like apache mpm worker or event) or calling the libphp from a threaded app you must build everything with thread-safe support. With fastcgi or mpm prefork that's not needed and in fact the default is to not build a thred safe php. But while a TS php can work in single threaded apps, the opposite is not true and the bugs may be subtle to be found. I agree with you that mixing extensions compiled with different options is something that usually happens when you manually build ports (and perhaps you were referring to this with zts handling), but that's exactly the reason to have it. If there are ports that install extensions in the non-zts directory when php is built with zts, then this should trigger an alarm: was the extension really compiled in thread safe mode? If so, why did it install in the wrong dir? The last thing you want is to call a non thread safe library from a threaded app.
Said so, I'm not completely against the removal of different directories, but if you do I'd like you to know exactly what were the original reasons so that you can verify that you are not hiding potential issues with its removal.

In D26848#599533, @ale wrote:

In D26848#599504, @tz wrote:

Are you sure it's your basic setting? The ports failing because of the ZTS option. And this option is broken since 7.0 or even earlier. Same for DEBUG option. See for example here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245034

So this is expected ;)

I don't know the status on 7.0 and later, so there may be a new issue I'm not aware of, but in all PHP versions I maintained it was working fine. The reason to use different directories is to avoid mixing extensions with different build options, e.g. if now I want a thread safe php I don't want to use an old extension compiled without thread-safety. Once the PHP port is installed, the correct directory is taken from the php.conf file, but if it's not installed yet there is an heuristic, that perhaps needs some adjustment.

In D26848#599355, @mfechner wrote:

I executed: poudriere testport -p gitlab -j 121amd64 lang/php80-extensions

But I got some errors:
https://pkg.fechner.net/build.html?mastername=121amd64-gitlab&build=2020-10-20_13h53m23s

I enabled some more ports in php80-extensions (the normal settings I use for all php versions).

In D26848#598658, @pascal.christen_hostpoint.ch wrote:

xmlrpc is also gone as an extension, right?
So no need to install the php7?-xmlrpc port for PHP 7.X

This was committed in r542132.
I forgot the reference in the commit log -.-

In D25648#567498, @bofh wrote:

This bug is not very easy to reproduce; specially this cannot be reproduced on a fresh poudriere jail at least. But I have faced multiple occurrences of this same scenario and changing to panda-cclient at least solve the problem. The diff looks good but I think we will need a bump in the PORTREVISION for php7[2-4] as the default OPTIONS are changing for slave ports.

Added the portbumps