file hierarchy overhaul. now a structure that makes more sense: user and core separated. we now differentiate between procedures and libraries - no more "profiles" - + some bug fixed + probably quite a few introduced + runtime directory + separated my own stuff more

1 files changed, 57 insertions, 20 deletions

diff --git a/README b/README
index 3d4bed5..eb14657 100644
--- a/README
+++ b/README
@@ -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
+