See also the FIXME's and TODO's in the code, and http://bugs.archlinux.org/toplevel/proj6

fix </boot>/vmlinuz depending on separate /boot -> $subdir wrong

CURRENT ISSUES:
* fix (hd0,0) not showing up in automatic procedure
* all grub related code could use a refactor
* do we use a squashfs on usb images?  is this needed?  how to make changes persistent?  
* time choosing: put 'ok' at bottom again but make it default
* implement depend_profile
* add /var/lib/aif/profiles directory to packages and document it.
*  check the existence of /src/core/pkg and based on that set a different default value. in interactive_select_source
* > It displays the current time in UTC (if utc selected) not the users localtime (UTC +- TIMEZONE)
* more vars for automatic profile: hostname (check that adding to /etc/hosts can be done procedure-independently), 
LOCALE, HARDWARECLOCK, TIMEZONE, KEYMAP, MODULES, DAEMONS, network config? (or take the config from runtime)
* what to do with /etc/groups, passwd, modprobe.conf, mkinitcpio.conf, rc.local etc with automatic procedure? configure through automatic profile or let user check out files from svn or so? 
* depend statements for automatic profiles (+ example)
* use traps and initiate rollback when user wants to abort. see also http://www.davidpashley.com/articles/writing-robust-shell-scripts.html
* differentiate between framework and installer in src/aif.sh, some things should be in base
* after unlocking dm_crypt, FS check fails (reiserfs, must try other)
* interactive FS display could use aligned columns. maybe with dialog --column-separator?
* sometimes we call die_error but we go back to the menu.. eg when we run as non-root and can't log
* fs_params in partition editor: do we really need to show them? isn't this where we store our "own" stuff?
* move "/tmp/pacman.conf" to runtime directory and variablize everywhere
* a nice way to be able to "inject" functions/logic without:
  * needing to redefine phases with only 1 entry different (duplicate code is not nice, less maintainable etc)
  * override worker functions which are 90% copy-pasted because the parent functionality is mostly okay, but not exactly what we want
  useful for: profiles for the automatic procedures, or all other procedures
  -> optional pre/post callbacks (for workers and phases)?
  -> disadvantages?
     * ended_ok must comprise callbacks too.. or if callback didn't exit cleanly, maybe we should update the exit code of the worker/phase
     * we lose semantics: a function usually has a better suited name then 'pre_<something else>'.
       -> maybe we should in the callback do an execute call for another worker, then we also can check it's exitcode in a good way
       -> too. although that's only good for separate functions, not the 'copypaste 90% and add 10% to the same worker scenario'
  -> phases are arrays.. adding elements at the back is easy.  for in the middle, we could maybe write some functions to add a worker before/after another in a phase
* show_report does not show workers.
* 'keep in mind trottled' not on separate screen
* look if you can hook into bash so that on any syntax/.. error you can bind the debug/log function
* when you have 2 LV's and you delete one, both are erased from the VG, but there is still the entry for the other one as blockdevice
* in usage, procedure specific opts points to parent profile when using inheritance
* refactor all pacman stuff (modularize/functionize etc)
* port from /arch/setup: grub install chroot thing (http://projects.archlinux.org/?p=installer.git;a=commitdiff;h=4565577dbd2182dd49612f1e0b68288f5573bf7b) (waiting for ticket http://bugs.archlinux.org/task/13277)
* ext4 default options? -O dir_index,extent,uninit_bg ?
* find a way to not have to preload libs and stuff, only load them when needed. -> faster start of install program
* core/interactive: do not check hard for the dependencies. a user could really know what he's doing or need to reboot after partitioning a disk and
skip that check or something.  Alternatively, maybe just show which steps are done successfully in the main menu
* support setting mount options for fs'es (to go into fstab) in at least automatic procedures. interactive > you can edit fstab right..


SOMEDAY/MAYBE/RANDOM THOUGHTS:
* core/interactive: do pacman -Sy in the background during early phases, to lessen the wait period before selecting packages
* write bash completion thing for aif modules/procedures
* add dmraid/mdadm support -> patches welcome.  i don't care about this. 
* check if it would be useful to support kickstart config files.  we can look at quickstart for that http://dev.gentoo.org/~agaffney/quickstart.php
* profiles like 'desktop','server' (~-> package list, configs, disk setup,..) are crossconcerns
compared to procedures (which are about "how" the installation goes:
prescripted, autodetection, interactive,...).
support for profiles could be built in certain procedures), maybe by supplying extra commandline
arguments to the procedure or asking a few questions.
For automatic procedures, a profile could be the fundamental entitiy,
whereas for interactive procedures it could provide some other defaults.
* all dialog windows are equally sized.  noone cares, right?
* we run mkinitcpio twice: one while installing kernel packages, once after configuring system (mkinitcpio.conf)
configuring the system (mkinitcpio.conf). can we optimize this?
* split up lib-ui as sep project, make a generic 'LIF' project, set $DISTRO somewhere and use that everywhere...


WORRIES FOR MAYBE NO GOOD REASON
* instead of every procedure using and overriding the 'base' procedure,
we should maybe have even more flexibilty to take parts from different, specific procedures.
eg: dieter procedure maybe wants to use something interactive. or base procedure wants to do something
from interactive profile (Will this really happen?)
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.. -> we can call explicit functions from libraries from modules.. so then just stick it in a lib ->
  lots of stuff can go into lib-ui, making the procedure itself just the
  'execution plan'.. sounds good actually.
problem with this is functions can have the same names (or you need to prepend modulename always, but that's not clean + 'fallback'/overriding doesn't work well anymore. 
alternative -> each lib is a directory, each function in a file, make it possible to source all libs, one lib, or one function from one lib