1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
|
See also the FIXME's and TODO's in the code.
ALPHA PHASE: get some people to test and suggest ideas, while fixing bugs and refactoring
General:
* setup bugtracker/roadmap thingie
* go over ALL files and check all function/executable calls are to existing
things (eg no dirty leftovers for functions that have been renamed)
* same for variables
* go over all files and clean up
* 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.
* by now we should be able to shift dia/cli in all procedures and everything
should keep working fine
* sometimes you can't see the whole question in ask_yesno (eg after manually partitioning/setting mountpoints)
-> maybe just increase the panel for all dia ask_yesno's -> fixed now i think with automatic height calculation
Specifically:
* core/interactive bug: boot space 15 -> too large should be too small
* core/interactive bug: swap space 0 -> invalid?
* core/interactive: keymap setting from installer does not go in $target/etc/rc.conf
* core/interactive: try out different installation methods
* core/interactive: manual filesystem mountpoints sometimes ok, sometimes filesystem creation is "very fast" and the filesystems are
not mounted under /mnt
* core/base: implement as specified in README
* core/quickinst: figure out what needs to be done and do it.
* dieter/automatic: wait for yaourt --config fix
* dieter/automatic: put config files from svn in place first, so that if a package has an update, it can do it's thing.
* on boot after fresh install sometimes filesystem creation date is newer then current date -> fsck. sometimes even forced reboot. (i've had this witch /arch/setup too)
BETA PHASE: try to get fifa 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...
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 fifa 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) ?
* 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?
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
|
