Lex and others,

a few additional thoughts (after thinking about it a while ;-) ):

I wrote:
> ...

> lex at cc.gatech.edu wrote:
> 
>>...

>>First, if I'm not mistaken, your capabilities model seems to boil down,
>>for each package, to this form:
>>
>>	(cap1 AND cap2 AND cap3)  IMPLIES  (cap4 AND cap5)
>>	(cap6 AND cap7)  IMPLIES  (cap8 AND cap9 AND cap10)
>>	
>>Is this correct?  You'd ask the installer tool to find a way to get you
>>cap10, and then it would trace backwards through all the packages to
>>know about to see if it can satisfy this.
> 
> 
> Yes.
> But the Caps can be hidden, so that the user asking for installing a
> package does not see them.
> And the mechanism allows to express more complex dependencies.

I have left out one important point: time is missing here!

What does this mean? Let me give an example.

Assumed you want to install a patch to another package: obviously it
needs the existence of the other package to be applied (otherwise it
wouldn't be a patch). So there is a *pre*requirement of having the
package installed *before* the patch.

Another scenario: say there is a library needed for some package, which
doesn't have to be there for installing purposes of the package (since
they are independent enough): then its OK first to install the package,
and after that the library, to get a working system *after* the install
process. There is a *post*requirement which has to be fulfilled *after*
the installation as a whole, but not before installing the package.

This is an example for the difference between incremental and
non-incremental installation.


The non-incremental variant is more comfortable for the dependency
resolver: it allows to temporarily remove a requirement as long as it is
provided again at the end of the installation process. In the
incremental case such a behavior would fail in many cases.


In the Boolean logic example above time is not an issue: but the world
is more complex than this example suggests.


Greetings
Stephan

> ...