Better overrides support for custom (and working) old_short_name values

Yeah, there is a problem if you have installed a site on Ubercart 3 platform when it used Standard D7 profile or acquia profile.

We had to move it to use Minimal, because we realized that if we will use Standard, it will never be possible to migrate any previously installed Ubercart site (which typically used acquia profile for legacy reasons), since Aegir already hardcodes the built-in upgrade path from D6 (default) to D7 (standard) and thus it is not possible (without hacking Provision) to provide upgrade path like acquia->standard or uberdrupal->standard etc.

Currently the hardcoded logic is as below:

    // Drupal 7 renamed the default installation profile to 'standard'
    // Aegir now allows projects to specify an "old short name" to provide an upgrade path when projects get renamed.
    if ($profile->name == 'standard') {
      $profile->info['old_short_name'] = 'default';
    }
    elseif ($profile->name == 'minimal') {
      $profile->info['old_short_name'] = 'uberdrupal';
    }
    elseif ($profile->name == 'testing') {
      $profile->info['old_short_name'] = 'acquia';
    }
    elseif ($profile->name == 'default') {
      $profile->info['old_short_name'] = 'acquia';
    }
    elseif ($profile->name == 'acquia') {
      $profile->info['old_short_name'] = 'default';
    }
    elseif ($profile->name == 'commons') {
      $profile->info['old_short_name'] = 'drupal_commons';
    }
    elseif ($profile->name == 'commerce_kickstart') {
      $profile->info['old_short_name'] = 'commercedev';
    }

Not sure how we could satisfy all conflicting legacy migration paths between profiles, so any suggestions are welcome.

Probably the easiest thing is to just add old_short_name = acquia (or old_short_name = standard depending on your site's current profile) to the new ubercart-3.5.1-7.24.1/profiles/minimal/minimal.info and re-verify.

https://omega8.cc/migrate-sites-between-installation-profiles-111

Yeah, normally it should work like this. We have started to force/pre-define some pairs for old_short_name because you can set old_short_name only when you have an access to the platform root, which is not the case with built-in platforms (unless you have a system root). This needs more work, though.

We have added extra Ubercart platform with different profile to cover most of possible issues:

http://drupalcode.org/project/octopus.git/commit/ad48177
http://drupalcode.org/project/octopus.git/commit/ac2184e
http://drupalcode.org/project/octopus.git/commit/2ff3abb

I hate to reopen this, but what would the BOA procedure now be to upgrade from D6 ubercart to D7 commerce?

It has been fixed, and for more details you may need to wait for release if it is too hard to determine from commits and the comment above.

Besides, you probably already know that there is no straightforward upgrade path for ubercart to commerce. BOA job is just to make it possible to use commerce platform as a target for ubercart based sites use any theoretically compatible profiles as source-target pairs, but this in no way makes it magically working out of the box if the profiles itself don't provide working upgrade path.

Oh, please note that this issue is *not* about ubercart to commerce upgrade path. I have managed to confuse myself after your question which has nothing to do with BOA, really. It is like asking how to upgrade Commons to Open Atrium. The issue here is mainly about Ubercart with D6 to Ubercart with D7 upgrade and confusion caused by profiles changes.

So, if you want to try to migrate ubercart site to commerce (which will explode probably anyway), you will need to follow standard docs: https://omega8.cc/migrate-sites-between-installation-profiles-111

Got it. Thanks for your feedback.

My reopen was more about overriding provision based old_short_name using the d6 ubercart to d7 commerce as an extreme example (my initial tests appeared as if provision takes precedence over .info settings, making further overrides impossible). I'll test in next release and create a new issues if necessary.

Current stable does override everything, but I think we have fixed this in head -- you could try this: http://drupalcode.org/sandbox/omega8cc/1074910.git/commit/0257b12