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
|
* 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
* in execute function: check exitcode of command and maintain variables like
worker_install_packages_exit=$?. Useful for: abstracting the phase
regulation in procedures like core/interactive, and also for reports at the
end of automatic installations
* phases should be specified as vars. eg phase_preparation='worker1 worker2'
advantages -> even easier syntax/overriding
we can easily track on a higher level (execute function) whether all workers
executed succesfully for a phase and set the exit state of that phase
moves all backend logic from phase to worker.
* make interactive procedure working well.
* base procedure wordt implementatie van alles wat auto gaat uit setup script, other steps warning 'not implemented'
* in elke phase een lege worker die te overriden valt zoda we geen phases
moeten overriden
* 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.
* instead of using the 'base' procedure and letting other procedures override,
we should have even more flexibilty to take parts from different procedures.
eg dieter procedure maybe wants to use something interactive. or base
procedure wants to do something interactive. 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
* base procedure idea: it should just tell you what to do? -> less
implementation work in base procedure, more in other procedures...
* fix crossconcerns: procedures are about _how_ (autodetection, asking user,...)
what about _what_ (desktop,server) --> 'mode'? 'profile'? procedures
define for themselves how much they care about the 'profile'. for some
it's a key thing, for others it could be just another list of defaults
* port classic installer so it works with fifa
* make some sensible default profiles (eg desktop, server, ...)
* make it work
* 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.. make a script '/arch/setup' that calls '/arch/fifa.sh interactive'
-- core/interactive --
- bugs -
* boot space 15 -> too large should be too small
* swap space 0 -> invalid?
* you always need to press ok before it does the action it just said it's
doing (is it the same with previous installer?)
- features -
* more control over filesystems (lvm,dm_crypt, choose each FS and each size
yourself)
|
