path: root/TODO

See also the FIXME's and TODO's in the code.

CURRENT ISSUES:
* 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
* check everywhere that if users cancels something, we return 1, empty string behavior etc
* dm_crypt unlock at boot is in qwerty.
* after unlocking dm_crypt, FS check fails (reiserfs, must try other)
* find a way to make _cli_ask_checklist still userfriendly for long lists.. maybe we should just propose/ask to use dia if the list is too long
* sometimes we call die_error but we go back to the menu.. eg when we run as non-root and can't log
* automatically configure grub for dm_crypt and lvm
* 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
* not all packages are shown when automatic procedure invoked pacman to install packages
* 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
* mirrorlist config doesn't change after selecting mirror
* 'keep in mind trottled' not on separate screen
* 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
* we may have an issue with ftp based installation where package installation works fine, however it tries to die instead of 'package installation complete' but it can't die because the --textbox fails in show_warning
* the old installer asked a lot of questions before actually configuring the system, eg like 'do you need support for booting from nfs/softraid/lvm2/encrypted, custom dst file?' etc.\
  do we still need this? why (not)?, and a select tag thingie would be nicer imho
* refactor all pacman stuff (modularize/functionize etc)
* aif : na "mijn" partitielayout: bij grub ( nog voor text editor op menu.lst) zegt iets ( op foreground van ncurses) Can't remove.. ik denk zelfs 'Grub: Can't remove..' en daarna een gewone entry, geen uuid's gewoon /dev/sda3 ro
* 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 maybe ntp to set clock
* auto-configure mkinitcpio.conf for dm_crypt and lvm
* core/quickinst: figure out what needs to be done and do it.
* right at the end of package installation something happens :/ also at configure system, before generation of locales


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
* the quickinst assumes the user did some stuff by himself and does some
after-processing.  Would it be useful to have a procedure that always tells
the user what to do (manually) ? -> ASKDEV
* 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
* base procedure is mostly to serve other procedures.  If we need to do much
work to implement something in the base procedure that we will probably
never use in other procedures, we're doing something wrong.  If that ever
happens (not likely I think), let's rethink what the base procedure should really be.

* 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