diff options
Diffstat (limited to 'README')
-rw-r--r-- | README | 77 |
1 files changed, 57 insertions, 20 deletions
@@ -15,30 +15,27 @@ The goal of this project is 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 profiles 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 +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 profiles (installation procedures) and combine them -together to come up with the installation procedure of your liking. +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 -* libraries -> /home/arch/fifa/lib -* docs -> /home/arch/fifa/docs -* profiles -> /home/arch/fifa/profiles -* pkg list -> /home/arch/fifa/packages-list (can be overridden) +* 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 ** -Profiles are stored like /home/arch/fifa/profiles/profile-* -You can put your custom profiles there too. Give them a recognizable name -that doesn't exist yet. - There is a very basic but powerful workflow defined by variables, phases and workers. -Depending on the profile you choose (or write yourself), these will differ +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> (a function that calls workers and maybe does some stuff by itself.) @@ -46,12 +43,52 @@ In the code, they are very recognizable and are named like this: - worker -> worker_<baz> ( a worker function, called by a phase. implements some specific logic. eg runtime_packages, prepare_disks, package_list etc) -If you specify a profile name other then base, the base profile will be sourced first, then the specific -profile. This way you only need to override specific things. +If you specify a procedure name other then base, the base procedure will be sourced first, then the specific +procedure. This way you only need to override specific things. Notes: - - you _can_ override _all_ variables and functions in profiles, but you should be able to achieve your goals by - overriding things of these 3 classes - - you _must_ specify a profile, to avoid errors. take 'base' if unsure - - don't edit the base profile (or any other that comes by default), rather make your own. It's easy! - 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! + +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 need a library from another user contributed module, execute +'depend_module <modulename>' for each module. +(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>' + + +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 + |