I too share a concern about the notion of "distributions" in the context of AgriDrupal. 

However, I don't believe that there is an intent to create a distribution of Drupal that will meet the needs of everyone that might want to create an Agricultural Information system based on a CMS.  AgriDrupal certainly doesn't comply with the Drupal definition of a "distribution" in the same manner that the Open Publish or Tattler projects do it.

To me, the downloadable code which can be deployed as "AgriDrupal" is merely a customization of Drupal that serves as a skeleton for further customization.  That said, there are still configuration management issues that are certainly not unique to using Drupal or any other downloadable project that includes code under active development.

In the context of the AIMS site AgriDrupal isn't a project, but instead a "Group" or community of practictioners although it does include a reference implementation that has undergone several releases.  As I see it, it's the community that's more important than the actual code one can download. 

The issue you bring up however, is really a configuration management issue, that as a community of practitioners we can all contribute on how to best address the issue.  One way to accomplish that is to attempt to adhere to a recommended (by the community itself) set of best practices.

Fortunately, Drupal has numerous tools which can assist in configuration management issues.

The first is that there are Drupal conventions (some are more enforceable than others) for contributed code development.  For example, almost every contributed module includes a module.install file.  It's not only responsible for instantiating underlying dependencies such as module specific database tables and variables, it also implements a convention for upgrading the module itself.  In other words, if someone in the community contributes a customization of AgriDrupal, following the "drupal way" of implementing modules and themes will allow AgriDrupal implementors ot more easily manage local customizations. 

The second really useful tool is the Drupal drush command.  The drush command (not really a module, though it's downloadable from the Drupal projects site:  http://www.drupal.org/project/drush)  along with the the drush_mm and  drush_sm companion modules are very useful tools for not only keeping modules and themes updated but they also can be used to import/export custom content types, views, etc.   The drush make project takes this a step further and allows someone to create a collection of modules, and install code not only from the drupal site containing contributed modules, but can install,  enable, and configure code from a version control system and even apply patches to contribed code. 

The use of drush make could lead to the use of version control systems such  as subversion or GIT to distribute custom modules that could be layered on top a basic AgriDrupal source code release.

Recently I played around with another configuration management module available for drupal called "Features".  Features leverages the drush make command and provides a nice facility for managing, distributing, and deploying a "feature" that might be added to an existing distribution.   For example,  a drush make file which downloads and installs dependency modules (i.e. the Feeds module and it's dependencies) and a features file which instantiates custom content types, configures a Feeds importer, and even provides several views could effectively add "OAI Harvesting" to a site without forcing a drupal administrator to manually go through numerous step to implement that functionality.  The features files itself is versionable so, as the base distritubution of AgriDrupal is updated any required changes to to "feature" can be updated as well.

I don't know where configuration management tools sits on the AgriDrupal roadmap but it seems to me, a discussion of these tools,  perhaps coming up with some recommended best practices for configuration managemernt and the inclusion of the drush tools as part of the "official" AgriDrupal release could help facilitate AgriDrupal as a maintainable project.    I think the project could also benefit through the use of a source code repository for those that want to contribute enhancements to the AgriDrupal code base as well as a Features servers for distributing some fo the features rather than bundle everything into on AgriDrupal zip file.

This module will be available by the end of July. When it is ready, we will post the download link on this website and after some testing we will commit it to the Drupal community.

In the meantime, in a few days we will post detailed instructions and code on how to implement an Agrovoc search and indexing functionality in any Drupal installation.