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

Reply via email to