* base procedure wordt implementatie van alles wat auto gaat uit setup script,
other steps warning 'not implemented'
* in automatic-dieter: health check using svn info /<hostname> 
* in elke phase een lege worker die te overriden valt zoda we geen phases
  moeten overriden
* process and fix libraries
* fix to use $var_UI_TYPE where needed
* write the ui functions for asking questions etc for both cli and dialog and port all code to use it. 
* instead of using the 'base' procedure and letting other procedures override,
  we should have even more flexibilty to take parts from different procedures.
  eg dieter procedure maybe wants to use something interactive. or base
  procedure wants to do something interactive. interactive functions maybe
  dont belong in a procedure?  -> depend_procedure good enough? or do we
  need more fine-grained dependencies (take function foo from procedure bar
  from module baz). for now let's try like this..
* base procedure idea: it should just tell you what to do? -> less
  implementation work in base procedure, more in other procedures...
* fix crossconcerns: procedures are about _how_ (autodetection, asking user,...)
  what about _what_ (desktop,server) --> 'mode'? 'profile'? procedures
  define for themselves how much they care about the 'profile'. for some
  it's a key thing, for others it could be just another list of defaults
* port classic installer so it works with fifa
* make some sensible default profiles (eg desktop, server, ...)
* make it work
* someday.. make a script '/arch/setup' that calls '/arch/fifa.sh interactive'