Thoughts:

- First compute state, then resolve dependencies

- To compute state, levels are needed. State must be
  computed level by level, starting at the lowest.
  Without it, cycles are introduced (state is computed
  by looking at freshen dependencies which are targeted
  at _installed_ resolvables. These must be fixed, else
  the freshen target would change later)
  Lowest level is package.

- Levels are not hard-coded inside the resolver but an
  attribute of ResKind.

  For the currently know Resolvable Kinds, the following order
  seems appropriate

  Package
  Pattern
  Patch
  Product

  A dependency can only be targeted at the same or a lower level
  (a patch can depend on patches, patterns, or patches. But not
   products).

  Dependencies which do not meet this requirement are ignored.
  A warning is issued.


Problems:

- patches which are add-on functionalities
  i.e. Nvidia driver, it has no freshens

- A freshens B must result in B requires A
  Changing the state of a freshen target (freshened) must trigger recomputation
  of the freshen source (freshening) state.



API

- Register Kinds and Levels with Resolver

- Resolvables 


- establishState()
  returns context with state, for all resolvables _above_ packages

  - installed (fully installed)
  - uninstalled (fully uninstalled)
  - incomplete (installed, but not all _direct_ requires are met)
  - satisfied (uninstalled, but all _direct_ requires are met)

  ! Only looks at direct requires !

  Implementation: QueueItemEstablish (resolvable)
    looks at resolvable. If it has freshens, checks these.
      If no freshens apply, it is satisfied
      If any on freshens apply, its requires are checked _non-recursively_
	If all requires are met, it is satisfied
	If any one requires fails, it is incomplete


- resolveDependencies(context = NULL)
  recursively resolves dependencies
  if context given, turn this into a series of install/uninstall requests
  before starting computation

  At this point, freshens must be considered.
  For this, the World as foreachFresheningResolvable(name, ...) which is implemented
    as a multimap of [name, resolvable] if resolvable freshens name.

Tests:

I. Installs

- freshen functionality

1. A-1.0 installed, Patch-A-1.1 freshens A < 1.1 to A = 1.1 -> install A-1.1
2. A-1.1 installed, Patch-A-1.1 freshens A < 1.1 to A = 1.1 -> do nothing
3. B-1.0 installed, Patch-A-1.1 freshens A < 1.1 to A = 1.1 -> do nothing, Patch-A-1.1 is satisfied
4. Patch-A-1.1 installed, Patch-A-1.2 freshens Patch-A-1.1  -> install Patch-A-1.2

- multiple freshens

- foo, foo-devel

- multiple targets

kernel-up, kernel-smp in a single patch

-----------------------------------------------------

II. Changes

Install foo-devel with Patch-foo installed -> install newest foo-devel
Delete A with Patch-A installed -> move Patch-A from installed to satisfied
Upgrade A above Patch-A -> move Patch-A from installed to satisfied

III. Patchlevels / Products


-----------------------------------------------------

Cases to cover


Installed/Uninstalled	| Freshens?	| Triggered?	| Requirements	| State
----------------------------------------------------------------------------------------------------
Uninstalled		| empty		| -		| -		| Unneeded
Uninstalled		| non-empty	| N		| -		| Unneeded
Uninstalled		| non-empty	| Y		| not met	| Incomplete	(-> needed)
Uninstalled		| non-empty	| Y		| met		| Satisfied	(-> complete)

Installed		| empty		| -		| not met	| Incomplete
Installed		| empty		| -		| met		| Satisfied
Installed		| non- empty	| N		| not met	| Incomplete
Installed		| non- empty	| N		| met		| Satisfied
Installed		| non- empty	| Y		| not met	| Incomplete
Installed		| non- empty	| Y		| met		| Satisfied


ResStatus

current		future				meaning
uninstalled	to-be-uninstalled		uninstallable
