This causes the Symfony Process component's `sigchild` detection to default to "no". From my inspection of the `debian/rules` file in for latest PHP package, this happens to be the correct behavior for the Process component to take, but this is simply out of dumb luck. What happens when/if that changes in the build routine and suddenly Ubuntu passes `--enable-sigchild`? At that point, the Symfony Process component will be making the wrong assumptions about how to handle this because the required information to detect this is missing.
See the following GitHub issue for when this issue was discovered (it has existed like that now for some time because it just *happened* to work, and the Symfony developers made the *correct* assumption that distributions would not modify the expected and documented behavior of php info: https://github.com/symfony/symfony/issues/23568#issuecomment-317775279 I'm positive other feature detection uses exist. IMHO, removing standard php_info() output sections for the purpose of lessening your invalid bug count seems like an absolutely horrendous excuse. ** Bug watch added: github.com/symfony/symfony/issues #23568 https://github.com/symfony/symfony/issues/23568 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/516061 Title: configure command line missing from phpinfo To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/php5/+bug/516061/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
