So let's look a little more closely at how GenericSetup achieves all of this wonder and magic.

First, GenericSetup introduces the idea of the configuration profile.  A profile is a set of XML files that describe the configuration of your site.  Note the fundamental difference between a profile and an install method; install methods define a set of steps that must be run to get a result, while a profile actually describes the result itself.  This makes a lot more sense, semantically.  It also brings site configuration down from the lofty clouds of programmer-land, to a realm where non-programmer-type site managers might even be able to look at the configuration and understand what it means.  Imagine!

What does a GenericSetup profile look like?  Well, you can see a very simple demonstration profile that has been recently added to the GenericSetup software itself.  If you want to see a much more complex profile, you can look at the default Plone profile.  I won't go into detail, but I will point out a couple of things these profiles have in common.

First, you'll notice that they both contain "import_steps.xml" and "export_steps.xml" files.  The import_steps.xml file defines all of the steps that need to be taken when this configuration is loaded into your site, while export_steps.xml describes the steps that should be taken when you want to generate a new configuration profile from the live site.  If we look a little bit more closely at the import_steps.xml file, we'll see that it contains a number of <import-step> tags, each of which have an id, a version, a title, and a handler (more on what these mean later).  Some of them also contain one or more nested <dependency> tags.  These dependency tags allow you to specify that certain steps must be run before other ones.  For instance, it does us no good to configure the actions tool (which is handled by the "actions" import step) before the actions tool is instantiated (which is handled by the "toolset" import step).  Therefore, in the "actions" import step you'll typically see the following nested tag: <dependency step="toolset" />.

Next, you'll see that there are a bunch of other files.  Each of these other files deals w/ a specific aspect of your site's configuration, and is usually related to a single step that was included in the import and/or export steps.  Common examples of these additional files include:

toolset.xml

Registers all of the tools available to the site. This must happen before the tools are configured.

skins.xml

A list of all of the skin paths that should be added to the skins tool when your site is configured.

skins(folder) 

Contains all of the templates, images, and css files for your skins.

types.xml

A list of all of the types that should be defined in the site's portal_types tool.

types (folder)

 A folder containing other XML files, one for each type listed in types.xml.  Each file contains detailed configuration information related to the specific custom content type for which it is named.

workflows.xml

Registers all of the workflows for the product (those in the workflows folder).

workflows (folder)

Contains the workflow definitions. Each subfolder contains one workflow. The workflows consist of a definition.xml file, and any supporting scripts necessary for the workflow operation.

An important point to note about profiles is:  Not all profiles are created equal.  In fact, there are two types of profiles that GenericSetup understands. 

The first type is called a base profile.  Base profiles, as you would guess, provide the base level information that a site needs to be created.  In Plone 2.5, Plone's default setup is itself a GenericSetup base profile.  Base profiles contain configuration information such as tools, workflows, types, register plug-ins for some packages. Most people building custom sites with will not need to ever create a base profile, and you should not create or alter your base profile until you have some practice.

Extension profiles are meant to be applied after base profiles.  Any number of extension profiles can be applied to a site, whereas only a single base profile is ever be applied. Extension profiles are meant to describe new content types, custom skins, custom workflows, custom tools, and add
their configuration to what has already been set up in the base profile. All of these are additive actions, that is they do not make any changes to currently existing products. Changing configuration in existing tools, modifying content types to respond to different workflow, or any other modifications of the base profiles, are less safe actions, and only should be undertaken when you know what you are doing.

To see an example of the profile that describes your current site, and illustrates these concepts, export a snapshot, and take a look at what is done.

Starting to make sense?  Great!  Onward and upward...