This proposal seems needlessly complex...in fact, I'd argue that this 
model is more complex than Envy or Store, not less.  You have defined a 
number of entities here that I'm not sure have been sufficiently defined:

  Module
  Bundle
  Package
  Module Requirements
  Configuration
  Map

First, what is a "Bundle"?  And what does it mean for a bundle to 
contain something?  The containership relation is ill defined.  Is a 
bundle something that when loaded, you also load all of it's children?  
If that's the case, then why not use a configuration for that?  Or, is 
it a grouping of things that are logically related?  If that's the case, 
then I can't see how a bundle is of any more utility than good 
documentation.

Also, it seems that that the only thing that a Bundle and a Package have 
in common is that they are nodes in a hierarchy.  Thus, without a 
meaningful definition of the containership relation, Bundle and Package 
really have nothing in common, which makes the Module class lose all 
meaning.

Personally, I think that Packages and Configurations are all that is 
really needed, and it's really simple.  A package is some body of code 
(that has certain implicit dependencies) and a Configuration is a 
specification for loading a set of package versions (where the 
configuration may specify any number of packages or configurations).  
Configurations and packages can be versioned.  Configurations can be 
tested for consistency and images can be queried for loaded packages 
and/or configurations, and a configuration can be generated based on the 
contents of an image.

- Stephen

Peter van Rooijen wrote:

>Goran, Stephane, et.al.,
>
>I saw your discussion about code control: dependencies (module
>requirements), package configurations, bundles, packages, etc.
>
>I have some experience and have done some work in this area, and I thought
>it might be helpful to present a code control scheme that I feel could work
>well for Squeak. It's a design that is quite a bit lighter-weight than Envy
>or
>StORE, and much more powerful than simple class categories and variants of
>that. It requires no change to the way the image works with code, yet it
>provides versioning, dependency management, build control, and support for
>a distributed repository.
>
>I would be happy for this design to be used as a basis for discussion or
>implementation.
>
>Squeak Code Control Proposal
>
>INTRODUCTION
>
>This is a relatively simple, but not too simple, scheme of organizing code
>that I have come to like after working with a few home-grown code control
>systems and vendor-supplied ones such as class categories (StX, Squeak, old
>VW), Envy (VA), StORE (VW) and the Dolphin PackageManager.
>
>This scheme does /not/ introduce a concept of code (classes and methods) as
>managed entities (things that have their identities and versions separated).
>Looking at classes and methods as entities managed by the code control
>system is not required. The code can stay in all the usual types of files.
>So this is one way in which the scheme is simple. It changes nothing about
>how Squeak already works in using images and image files.
>
>THE DESIGN
>
>1) Let's assume, to define terminology for the sake of argument, that when
>talking about dependencies and configurations, we are thinking of all the
>code (the classes and methods that do the actual work) that is involved as
>being contained in a Module.
>
>    - A Module is either a Package or a Bundle.
>    - A Bundle contains (zero or more) Modules (composite pattern!).
>    - A Package contains code = classes and methods (i.e., no other
>Modules).
>
>2) Let's note that there is a versioning aspect to this domain. When we talk
>about a Module (a Bundle or a Package), we actually have two notions to deal
>with:
>
>    - The Module identity (the thing that groups all its versions).
>    - The Module version.
>
>[When we talk about Module, Bundle or Package, we often /implicitly/ mean
>either the identity or the version. When devising a code control system, we
>must actively keep the distinction in mind, and I will do so in the rest of
>this proposal.]
>
>3) Module Requirements and Configurations are declared things (someone
>defines them, as opposed to them being dynamically derived), which both
>describe relationships between Modules (Configurations additionally describe
>relationships involving Maps and Modules - see below).
>
>    - Module Requirements describe dependency relationships between a
>(requiring) Module /version/ and the (required) /identities/ of other
>Modules.
>
>[Calling these relationships Module Requirements (i.e., not "dependencies")
>allows talking about "requiring" and "required" modules as specified by a
>Module Requirement. Module Requirements are also very specific things
>whereas dependencies can be understood more as a broader concept that Module
>Requirements address.]
>
>    - Configurations describe relationships /between versions only/.
>
>[Module Rrequirements are semantically different from Configurations and
>they express different concerns"
>
>    - Module Requirements express what Modules are (thought to be) required
>for the the declaring Module to function correctly. Multiple versions of a
>particular required Module may work, so a Module Requirement points from a
>requiring Module /version/ to required module /identities/.
>    - A Configuration expresses exactly which code will be installed when
>the Configuration is loaded into an image. So, a Configuration points only
>to Module /versions/.]
>
>4) In order to be able to describe the code state of a whole image, which
>contains multiple Modules, we need a higher-level managed entity than the
>Module. Let's call this a Map. A Map is a managed entity with separation
>between its identity and its versions. A Map version has a Configuration
>(remember: Configurations are exact and point only to versions). The
>Configuration of a Map points at zero or more versions of Modules (Bundles
>and/or Packages) and zero or more versions of other Maps.
>
>5) All managed entities (their identities and their versions) can be stored
>persistently in a repository, completely separate from any images.
>
>So, a repository contains:
>
>    - Maps (identities and versions), with each Map version having a
>Configuration.
>    - Bundles (identities and versions), with each Bundle version having a
>Configuration and a Module Requirement.
>    - Packages (identities and versions), with each Package version having a
>Module Requirement. Each Package version also knows the location of its code
>(classes and methods).
>
>[The code of Package versions may be stored in external files, a local or
>remote database, somewhere behind a URL, whatever. We can only hope that the
>code will indeed be found there, but even it isn't, the functioning of the
>repository itself will not be hindered by that, merely the ability of
>loading the code for that particular Package version]
>
>Comments are welcomed.
>
>Regards,
>
>Peter van Rooijen
>Amsterdam
>
>
>  
>