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
|
See also the FIXME's and TODO's in the code.
PRE-ALPHA PHASE: get it sort of reasonably working
* core/interactive bug: -> configure system -> fstab (/mnt//etc/fstab) does only contain pts,shm and floppy/dvd/cdrom. not hd's? ->this breaks the boot procedure!
ALPHA PHASE: get some people to test and suggest ideas, while fixing bugs
General:
* 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.
Specifically:
* core/interactive bug: boot space 15 -> too large should be too small
* core/interactive bug: swap space 0 -> invalid?
* core/interactive bug: autogenerated grub menu.lst:
- 0) devices are /dev/hda, not sda :/
- 1) windows entry looks okay
- 0-1-3 again! (3)windows looks okay again), 0-1 use uuid's which are correct
* core/interactive: keymap setting not kept? (note: next time check rc.conf values during configure system)
* core/interactive: /mnt//etc/fstab -> // ?
* core/interactive: try out different installation methods
* 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
BETA PHASE: try to get fifa on the (beta) installcd as an experimental, alternative installer.
* involve broader community
* setup bugtracker/roadmap thingie
* fix everything
PRODUCTION PHASE: totally replace /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)
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?
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
|
