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
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
|
FIFA is a Flexible Installer Framework for Arch linux.
--- Very, very early in development. Use at own risk!! ---
Licensce: GPL3. See COPYING.
Author: Dieter Plaetinck
Homepage: http://github.com/Dieterbe/fifa
** Goals **
The goal of this project is
1) to allow you to install Arch Linux in more flexible and powerful ways.
2) write an automated (unattended) installer
3) Apply DRY patterns to the installation procedure, making it more easy to maintain the code.
You can choose to use unattended (automatic) installation (you can write different
modules/procedures for different scenario's, and/or use autodetection) or prompt the user for whatever you want to know (you could mimic the official installer like
that).
You can also take parts from different installation procedures and combine them
together to come up with the procedure of your liking.
** File locations (on the install CD): **
Basically fifa.sh is put in /arch (together with the default installer scripts), while all other fifa-related files belong in /home/arch/fifa
* fifa.sh -> /arch/fifa.sh
* docs -> /home/arch/fifa/docs/
* core module -> /home/arch/fifa/core
* user modules -> /home/arch/fifa/user/<module name> (put your own modules here)
* runtime files -> /home/arch/fifa/runtime (package list etc go here)
A module can have 2 directories: libs, and procedures.
** Workflow **
There is a very basic but powerful workflow defined by variables, phases and workers.
Depending on the procedure you choose (or write yourself), these will differ
In the code, they are very recognizable and are named like this:
- variable -> var_<foo>
- phase -> phase_<bar> (an array in which each element is a worker to be executed, with optionally arguments for that worker)
There are 4 phases: preparation, basics, system, finish. (executed in that order)
- worker -> worker_<baz> ( a worker function, called by a phase. implements some specific logic.
eg runtime_packages, prepare_disks, package_list etc)
You can depend on whatever procedure you like (like core/base), to save
yourself some work (you only need to override a few things)
Notes:
- The phases are started by the start_process function. You can also override this function to take flow control in your own hands (eg iterative, menu-based installer)
- you _can_ override _all_ variables and functions in your modules, but you should be able to achieve your goals by
overriding only the 3 basic things and the start_process function, and only in procedures.
- you _must_ specify a procedure, to avoid errors. take 'base' if unsure
- don't edit the base procedure (or any other core item), rather make your own. It's easy!
- you're not supposed to define new phases. just override them. logic goes in workers/libariers
Modules are the building blocks in fifa. They can contain libraries (for
user interfaces, backend logic, etc) and procedures (how an installation
process should go).
The core module comes by default and contains everything 99% of the users
will need. You can easily make your own modules with in it your own
procedures (and your own libraries, if you need that). If you build your
own libraries, it's generally a good idea to keep
their names in line with what core has (lib-ui.sh, lib-network.sh etc).
Do not put stuff in the core module yourself! If it's good stuff, it might
be merged into core someday... Also, don't name your custom module 'core' (it will be
ignored anyway). Don't call it http either, because you can specify
'http://some/path/to/a/procedure', fifa will download that procedure and
execute it (and the module will be 'http')
Note that if you load a module and a library has the same function names as
the core module, it will override the functions from core.
This means you can 'inject' new backend code into core procedures, but you
can also write your own procedures that use your own, or the core libraries.
If you load a module, you actually load it's libraries, not it's procedures!
Procedures are only loaded when needed (because you request them because
of dependencies)
If you need a library from another user contributed module, execute
'depend_module <modulename>' for each module. This way you load all the
libs of that module (not the procedures, use depend_procedure for that.
keep in mind that the position of the depend_procedure statement defines
where your variables/functions might be overridden...)
(very basic dependencies, no version checking etc)
You can specify a core procedure on the command line by specifying
'<procedure_name>', to specify a user contriubuted procedure, specify
'<module_name>/<procedure_name>'
If you want to do debugging, just call the debug function and export DEBUG=1
before calling the scripts.
Much of the code in the core module is taken (and modified) from the 'real' arch linux install
scripts code. (/arch/setup and /arch/quickinst). the modifications are mostly done
to make the code more (re)useable and to separate backend code, user
interface and flow control. (intro libraries and procedures). (which was tightly coupled in the original scripts)
I couldn't find what license the code is under, but I assume this
is okay.. if not let me know.
The original code is at
http://projects.archlinux.org/?p=installer.git;a=summary
|
