goran.krampe at bluefish.se wrote:

>Hi!
>
>Stephen Pair <stephen at pairhome.net> wrote:
>[SNIP]
>  
>
>>It's important to note that the "requires" clause in my notation is 
>>simply a name...the requirement is not tied to an specific package or 
>>package name...it is only a name.  It's the configuration that 
>>determines what package and version will actually get used to satisfy 
>>the "requires" clause.
>>    
>>
>
>Hmmm. It is nice that you agree with this simple model (no boolean
>algebra, no >= etc, not having this info inside the package, ability to
>have multiple configs).
>
>But what are the advantage of these names and these requires clauses? I
>would like to understand that.
>

In order to enumerate the advantages, I have to know what I'm comparing 
it against.  How else would you declare that a package has a 
prerequisite?  It is these names that *do* appear within a package 
version.  It is the configuration that binds these names to specific 
versions of specific packages.  You have to have some way of declaring 
that a dependency exists (and you need to allow the list of dependencies 
to change from version to version). 

For example, KomServices 1.0 has a prerequisite called 
"DynamicBindings"...based on feedback I've received, I'm going to remove 
that pre-requisite in version 1.1 of KomServices.  Therefore, I need a 
way of specifying that version 1.0 does have this prerequisite called 
"DynamicBindings", whereas version 1.1 does not.  The name of a 
pre-requisite is arbitrary...I didn't have to call the pre-requisite 
"DynamicBindings"...I could have called it whatever I wanted...the point 
is that there exists this notion of a prerequisite to something that 
provides dynamic bindings like functionality that exists in 1.0 and is 
being removed in 1.1.

- Stephen