Aegir forces default profile on site import and on first verify breaks the site by disabling all non-core modules

I've just reproduced this:

Copy an atrium platform + site from one aegir system (running HEAD) to another, and on import of the site, the profile is 'default' (machine name rather than 'nice' name).

For a long time (since March '09 when the hosting_package_instance_load function's query got changed) we have been making calls to hosting_package_instance_load() but without specifying the table of the attributes (i.e asking for rid and shortname instead of i.rid and p.shortname), as originally it was just a SELECT ALL from one table with no joins (see this commit).

This affects more than just this ticket. Patch attached for myself and omega8cc to review before I commit..

I committed this, but omega8cc's frightened me into thinking it didn't fix the issue. :) So I won't mark this as fixed until it seems to have stopped imported sites from getting 'default' or 'Drupal' as the install profile.

Just going to chime in again and confirm that this is still a major problem and my patch hasn't seemed to have helped.

I just re-arranged my own aegir live install and imported platforms, and it screwed all my sites, setting 'default' profile everywhere, disabling modules, and in one case, even renamed the profile package with the title of another install profile (go figure).

So the whole thing is a big mess, and some things in provision/platform/deploy.provision.inc are just plain wrong, for example:

    $site_packages = drush_get_option('packages', array(), 'site');
    $profiles = array_keys($site_packages['profiles']);
    $profile = $profiles[0];

$site_packages here simply returns a null array. Something is seriously wrong with our package syncing stuff, and much of the rest of deploy that does the schema comparison stuff depends on having merged in the modules provided from profiles etc.

This is also the reason why you see 'array_keys' PHP warnings related to 'profiles' on deploy tasks (so import, migrate, restore etc).

Editing it to be this, *does* work, but I'm so confused by the packages logic that I'm not sure it's appropriate:

    $site_packages = drush_get_option('packages', array(), 'drupal');
    $profiles = array_keys($site_packages['profiles']);
    $profile = $profiles[0];

Also, why do we just take $profile[0] here? That's not necessarily the profile we have installed on the site if there are multiple profiles on the platform.

I think the reason it's null for the site context is because we do a provision_save_site_data() just prior, and thus the drushrc's rewritten and none of the profile packages (or probably *any* packages since we haven't done a sync or anything) are available.

So all the following code probably doesn't work at all:

    $merged_modules = array_merge($drupal_packages['base']['modules'], $drupal_packages['profiles'][$profile]['modules']);
    foreach ($site_packages['modules'] as $name => $module) {
....

I think this desperately needs Adrian's eyes, as the package stuff has always hurt mine..