Lower memory limit for php5

Attention: we should not go back to 8M, which would be too low, because the reporting of used memory has changed also. From the changelog of 5.2.0: "Increased default memory limit to 16 megabytes to accommodate for a more accurate memory utilization measurement."

This bug was fixed in the package php5 - 5.2.4-2ubuntu1

---------------
php5 (5.2.4-2ubuntu1) hardy; urgency=low

  * Merge from Debian unstable (LP: #176011). Remaining Ubuntu changes:
    - debian/control, debian/rules: Disable a few build dependencies and
      accompanying binary packages which we do not want to support in main:
      + firebird2-dev/php5-interbase (we have a separate php-interbase source)
      + libc-client-dev/php5-imap (we have a separate php-imap source)
      + libmcrypt-dev/php5-mcrypt (separate php-mcrypt source)
    - debian/rules: Correctly mangle PHP5_* macros for lpia
    - debian/control: DebianMaintainerField
  * Builds php5-gmp (LP: #176013)
  * Fixes sybase_ct for MS SQL (LP: #21995)
  * New Ubuntu changes:
    - debian/rules: use 32M memory_limit for CLI and 16M for cgi/libapache
      (LP: #148871)
    - debian/control, debian/rules: Configure CLI with --with-libedit for
      readline support again, now that the libedit issue is fixed.
      Extended debian/patches/027-readline_is_editline.patch (LP: #124846)
    - Force build against db4.4 (by ignoring db4.5 if it is installed),
      debian/patches/use-specific-libdb-version.patch (LP: #165247)

php5 (5.2.4-2) unstable; urgency=low

  [ sean finney ]
  * for posterity revised previous changelog to reference the CVE id's
    of security issues resolved by the latest upstream release.
  * lintian: use debian/compat instead of DH_COMPAT in debian/rules.
  * lintian: use source:Version and binary:Version where appropriate,
    instead of Source-Version
  * lintian: remove a couple pieces of cruft in the changelog that were causing
    false-postive wrong-bug-number-in-closes, but were generally useless
    anyway.

  [ Raphael Geissert ]
  * Using test-results.txt as a target
  * cronjob now checks for existance of /usr/lib/php5/maxlifetime (Closes: #439286)
  * Fixed memory limit of 1232M in php.ini for cli (Closes: #440624)
  * Build the interbase extension using firebird2.0-dev (Closes: #433736)
  * Unapply patches with debian/rules clean

  [ Steve Langasek ]
  * Don't patch configure or php_config.h.in in suhosin.patch, as these are
    auto-generated and including them in the patch results in a race
    condition for the necessary build-time regeneration. Thanks to Daniel
    Schepler for reporting, and to Damyan Ivanov for helping to sort out the
    fix. Closes: #443637.
  * Also remove the modified auto-generated files in the clean target,
    which triggers a warning about disappearing files when building the
    source package but avoids carrying irrelevant diffs to these files
    in the Debian diff.
  * Now that the testsuite is being run at build time, test failures cause
    a bunch of junk files to be left around in the Debian diff. So clean up
    several false-positive failures:
    - 052-phpinfo_no_configure.patch: we're patching the output of phpinfo(),
      so patch the test as well
    - fix_broken_upstream_tests.patch: use a local directory for tests that
      use sessions, skip the phpinfo test after all because it doesn't appear
      to be compatible with current testsuite behavior, and disable the
      moneyformat test if...

but still, in recomended php.ini memory limit is still 128M.

Most of the modern php aplications require higher memory limit than 16M that is now default in ubuntu. This may be a problem for some less experienced php developers that choose ubuntu as dev platform.

for them php is broken because their application doesn't work on ubuntu and does work on for example windows.

i to think that 128M is a bit much but i think 32M is a minumum nowdays.

i'm using some of then new php5 RAD tools like Propel, Doctrine, Cake, Symfony and their memory requirement is above default 16M.

Is it really that hard to change configuration value in one config file? I don't think so.

16M is safe default for web application if you don't want php to eat all your memory.

Nevertheless this bug is about having 1232M memory limit in CLI and not about raising memory limit. If you wish you can open new wishlist bug for this issue, but I don't think it should be changed nowadays.

no it isn't hard, but that's not the issue here, but for some more inexperienced users this could be a problem.

I've just created a new wishlist bug for a better/increased default: bug 196806.