Provide the full range of Drupal functions to .install files

Attached is a rough but working patch to install.inc that makes sure system.install is always executed first, then does a full bootstrap before kicking off any subsequent installs. I'm 100% certain others will find a cleaner way to do this (mine adds two convenience functions to the install system), but it works and is a good starting place.

Bumping up the priority. This is a bug, not a feature -- many many contrib modules will not install properly without it.

A reroll (patch complained a bit). And an RTBC. This is badly needed, for example, any .install that wants to do a variable_set will die.

Once this is committed, http://drupal.org/node/73660 will also be ready to roll as well -- it splits more of the module specific tables into separate install files. We're very close on the install stuff.

I'm not fully familiar with the new API, so I can only say I think this looks good.

The DB work of rthe profile should happen after the modules so it can override database things as necessary.

The original vesion of the file did execute things in that order -- fies the profile, then the module install files. After looking, I don't think that makes much sense.

I've re-rolled the patch with that one change: required modules first, profile-specified modules second, and the profile's custom _install hook after that.

This patch revealed a problem with our error handler: it always reported errors, even if the @ operator was used. This caused e.g. the chmod attempt for settings.php at the end of the install process to print additional visible warnings.

Patched by checking for @ in error_handler().

Committed to HEAD (without the test bit of code added to default.profile).

Bad approach for error handler, I think:

  // If the @ error suppression operator was used, error_reporting is temporarily set to 0
  if (error_reporting() == 0) {
    return;
  }

If error reporting is turned off, e.g.

  php_value error_reporting   0

then admins won't see the error, warning etc. happened even these without @ operator.

Best would be to change

  // If the @ error suppression operator was used, error_reporting is temporarily set to 0
  if (error_reporting() == 0) {
    return;
  }

to not return immediatly, but continue error_handler() execution.
Is it possible to avoid @ within Drupal sources?

setting error_reporting to 0 won't make php to display any errors before Drupal error handler is set up.

If the admin has error_reporting set to 0, they obviously don't want to see errors. What is your point?

We cannot avoid @ because some functions cause errors/warningsin relatively benign situations.

just a fyi: I've backported the common.inc change to 4.7.