path: root/TODO

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

* finish interactive_filesystems port to refactored code
* do the remaining bits in lib-blockdevices-filesystems
* test

ALPHA PHASE: get some people to test and suggest ideas, while fixing bugs and refactoring
General:
* setup bugtracker/roadmap thingie
* write the ui functions for asking questions etc for both cli and dialog and port all code to use it. 
* find a way to not have to preload libs and stuff, only load them when needed. -> faster start of install program

Specifically:
* core/interactive: gui transparancy: interactive autoprepare, package selection
* core/interactive: fix workaround needed for installpkg exitcode
* core/interactive: keymap setting from installer does not go in $target/etc/rc.conf
* core/interactive: manual filesystem mountpoints sometimes ok, sometimes filesystem creation is "very fast" and the filesystems are not mounted under /mnt
* core/interactive or lib-ui: don't echo the name/id of selection options in dia mode
* core/base: implement as specified in README
* core/quickinst: figure out what needs to be done and do it.
* time totally incorrect during install -> filesystem creation date is newer then current date -> on reboot in new system fsck. sometimes even forced reboot. (i've had this with /arch/setup too). a tool to configure the date? run ntp? (not always network available!) -> ASKDEV
* /home doesn't get made separately in automatic installer. it's not formatted in sfdisk or _mkfs'd.  is this only in virtualbox or elsewhere too?


BETA PHASE: try to get aif on the (beta) installcd as an experimental, alternative installer.
* involve broader community
* fix everything
* if dhcpd already runs for $reason, the installer will try again @ configure network and
fail.  i tried killall dhcpd, killall -9 dhcpd first but that didn't help:
it can't kill the process or something...
* 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

PRODUCTION PHASE: be the primary installer.  deprecate /arch/setup and /arch/quickinst
* fix everything even more
* bribe devs
* core/interactive: more control over filesystems (lvm, dm_crypt, choose each FS and each size yourself)
	when doing lvm install. copy /etc/lvm/backup to /etc on target (or maybe
	it can be regenerated with a command, i should look that up)
* core/interactive: when auto-setting up hard disk. show with a bit more detail what is happening (not 'partitioning <disk>' but partitioning, and each FS)
* 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


SOMEDAY/MAYBE/RANDOM THOUGHTS:
* 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 the system (mkinitcpio.conf). can we optimize this?
* core/interactive -> install packages -> dependency cycles with glibc.  not
a problem? -> ASKDEV


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