Example of sub-profile w/ makefiles compatible with Aegir

fyi - easiest way I found to upgrade drush to drush 5 is with the following command:

$ drush dl drush-7.x-5.0

obviously, you can change the version at the end. Find it on the d.o. project page

putting 2 different profiles in my stub makefile broke when i used Drush 5.0 - It complained about non-empty directories.

As far as I understand, from reading various (recent) posts in issue queues the stable version of drush 5 and hostmaster/aegir don't play 100% nicely together yet and I just had some troubles getting it to work myself on my local environment.

Since the OP specifically mentioned that they are working with Aegir, which means drush 4 (at least for now), I've updated the title of this issue to be more specific.

As far as addressing the issue where you can't pull down profiler into two separate profiles with the same makefile, since profiler is a library downloaded from a url rather than auto-detected from the d.o. project name you can do a little namespacing black magic like so:

Base profile:

libraries[base_profiler][download][type] = "get"
libraries[base_profiler][download][url] = "http://ftp.drupal.org/files/projects/profiler-7.x-2.0-beta1.tar.gz"
libraries[base_profiler][directory_name] = "profiler"

Sub-profile:

libraries[sub_profiler][download][type] = "get"
libraries[sub_profiler][download][url] = "http://ftp.drupal.org/files/projects/profiler-7.x-2.0-beta1.tar.gz"
libraries[sub_profiler][directory_name] = "profiler"

I've tested this and it works. Theoretically you should be able to do similar namespace tricks with any module or theme by setting the download type to "git" instead of the default "fire and forget" method of trusting the d.o. project name for everything.

I assume you don't want to duplicate all your modules/themes across both the base and the child theme, so that's the next problem.

According to #970980: Child profiles needs to duplicate module files Drupal sites installed on one profile can't see any code sitting in a different profile's directory. The suggested workaround is to put all code you want to share across all profiles in the /sites/all directory, which makes sense in a weird way but only because of Core's relatively simplistic definition of what a profile is.

As to how you actually *achieve* getting modules out of a profile and into /sites/all is another matter... A makefile discovered recursively in a profile cannot put any code that is downloaded outside the root of that profile as mentioned here #913148: Please bring back install_path. The suggestion of using project[modulename][subdir] = "sites/all/contrib" posted in #827632: modules inside sub-profile not available did not work for me, I ended up with my modules sitting awkwardly in "/profiles/
/modules/sites/all/modules".

In the end I split my project across 3 areas #1498284: How to include a makefile downloaded via git? so that my stub makefile contained:

* Reference to what I wanted to use as core (pressflow for me)
* An include for a makefile hosted on github that pulls down all code that needs to be shared between profiles
* My base profile
* My sub-profile

Anyway, that's as far as I got today. Will let you know how I go testing what can be inherited from the base profile in your sub-profile using this approach :)

Everything seems to be working as expected now :) but I had to pull in my "build" makefile as a module because of the way that drush make supports git. See the issue that I referenced in my last post.

Related: #1356276: Allow profiles to define a base/parent profile

I am closing this issue, as it has been created for a release that is now not supported.