php
php copied to clipboard
docker-library
add dtrace build
Hi, this PR introduce dtrace variant of php image, but debian omly, it would be really problematic on alpine.
Closes https://github.com/docker-library/php/issues/813
Unfortunately adding more variants of PHP is not something we want to support and maintain. Full build time of what we already have is around 2-3 hours (on each architecture). We do not have bandwidth for more PHP variants (https://github.com/docker-library/php/issues/530#issuecomment-353696536, https://github.com/docker-library/php/issues/879#issuecomment-816952523).
Also, this would seem to make more sense as a variant of each of the current variants (i.e. fpm-dtrace) rather than a variant unto itself which would double the number of Debian variants, greatly increasing queue build times.
With docker buildx there are possible optimizations eg. part of Dockerfile for installing dependencies could be cached and shared for each distro-arch build, this could save some bandwidth but I understand that most of time is spent in compilation process. Regarding fpm, if somebody needs dtrace-fpm, he could use simple multistage dockerfile and just copy fpm binary with confs and deps to dtrace image, without any compilation, but only case that there will be dtrace image available.
@tianon i've checked php source, should have no impact when disabled by env USE_ZEND_DTRACE=0 @yosifkit would you accept PR with dtrace enabled for all debian builds?
Sorry for the delay! That sounds like it might be OK, but my high level concerns beyond performance impact would be size impact and whether it's appropriate to enable across all the multitude of CPU architectures we support (I see Debian has been oscillating back and forth on this for a while and I'm guessing that's probably FTBFS related: https://salsa.debian.org/php-team/php/-/commits/debian/main/8.3/debian?search=dtrace :grimacing:). :bow: