It was quiet, I wonder why? Nevermind. I'll try and summarise my talk. The main aim was to describe some of the ideas behind the dependency and installer api we ( Adrian and me) were working for some time on. So what do we have now. We have packages - core, modules, themes, theme engines. We have both cvs and point releases with onoe offical module version per major release. We store thing in different locations - core or (sub)site directories, module, theme and misc directories. And put in the mix the dependencies modules on core, modules depend on other modules, themes depend on theme engines and possibly other modules. It can easily become daunting. Just summarise it things depend on either on an api , module or databse schema. Being lazy and feeble minded to manage to keep all of that data in mind and process it from time to time, we decided to implement a dependency api as part of the drupal installer. dependency.inc contains an api to discover and process dependencies between packages. It is not going to handle circular dependencies, they should be resolved during package definition. At the core of the api lies the dependency_process() function. It iterates through an array of $stages sequentially, to process a set of $modules and the ones they depend on, executing a callback, guarded by a $verify_callback, and throwing the errors using an $error callback. The order of processing is implied by the dependency order, that is if A depends on B, B is processed first. This process can be adapted to do staged installs, with update, dowenload, unpack, configure, upload, finalise workflows. Others are possible. With political correctness in mind and in order to simplify the structure of the packaging meta-data, we are suggesting the packages to be sexless, that is no distinction based on what is contained in a package - module, configuration, theme, etc... We want the packages to expose what they depend on, as well as their database schema, as well as some classification or tagging. The core metadata is proposed to be - package name, description, dependencies, tags, schema, version. Other application or package dependent metadata can be added. The description file format, mimics the debian control file format. It is easy to read, it allows describing virual or meta packages, could be reused by drupal distributors - for example debian, ubuntu, red hat, Novell, fink,... Maybe it's worth explaining what do we mean by a virtual package - it is a package which is used to describe dependencies, it does not contain any kind of data. By meta-package I mean a virtual package on steroids - it does have some configuration data, which, for example, can be used to configure a set of packages dependent on it. All this, allows for a flexible configuration and setup odf drupal distributions. It will ease the life of drupal users and distributors by automating a few of the error prone tasks related to manual package selection. The installation of drupal can be implemented in three generalised scenarios:

direct install

everything is done on the deployment webserver. It's advantages are that it is the least complicated for the user to deal with. The disadvanages are mainly from the potential security holes, coming from the design of such deployment - for example the ability to write files, which afterwards can be executed.

indirect web install

everything is done in a special controller, running on a webhost, for example withing control panel or webmin. The disadvantages come from the fact that users depend on their hosting provider to preinstall this controller.

staged install

basically an automated version of the current common install procedure. It can be modified for hosting providers as well.

As an added bonus, we will have better or more convenient upgrade system. An api to enable each package to handle it's own upgrades. We will have the possibility of migration packages. We will be able to repackage template sites and use them for subsequent installs. So briefly this was what I talked avbout on DrupalCON.