Installer might install modules in wrong order

Awesome. I had noticed this bug at one point but always assumed someone had already filed it somewhere and that it would take a lot of code to solve... glad to see that is wrong :)

My only minor comment is that I stumbled over the code for a second while reading it because it overwrites the $modules variable a couple different times for a couple different purposes. It might be a little cleaner to use a separate variable, something like this:

  $module_weights = array();
  foreach ($modules as $module) {
    $module_weights[$module] = $files[$module]->sort;
  }
  arsort($module_weights);
  $modules = array_keys($module_weights);

But everything about the approach looks fine. I guess an effect of this patch is that the order in which modules are listed in the profile .info file no longer has any relationship to the order in which they are installed. I don't think that's a bad thing; just might take a little getting used to after thinking for a while that you have to write down the modules in the order you want them to be enabled!

This looks good. Renaming the variables is not a hard requirement for me, so I proceeded with committing this patch. Thanks.

Also exists in D6. Would it be hard to backport patch? I could remove a lot of ugly hook_requirements() code from modules...

Dependencies aren't fully installed before the module that depends on them in D6, i.e., the module install order is incorrect. This causes WSoDs for the dependent module if it calls functions made available by its dependencies (see http://drupal.org/node/365098). I think it is reasonable to view this as a bug: D6 attempts to handle dependencies but causes errors when doing so. (It can't be a feature request, because handling dependencies already exists as a feature of the D6 installation system--it just isn't working properly.) The changes in this issue fix the module-dependency installation-order problems in D7; hopeful we can backport them to fix the bug in D6 as well.

I think this is a bug - it causes deadlocks like #655896: Bug in dependency locking on /admin/build/modules.

If a module's hook_requirements fails, it's dependents are installed anyway, and then you can't enable the parent even after fixing whatever failure there was, because the checkbox is disabled. It also makes it really damned hard to create versioned dependencies in hook_requirements (look at panels_requirements_install() for an example of the mess this bug creates).

This is still a problem, as of Drupal 6.26. Also, apart from this issue, it doesn't appear to be documented anywhere, e.g.: http://api.drupal.org/api/drupal/developer%21example.profile/function/ex...
http://api.drupal.org/api/drupal/profiles%21default%21default.profile/fu...

Not entirely sure, but we seem to be having the same problems here. The order of dependencies are sporadic which causes a (very rare) WSOD. Has this ever been ported to D7?