GENIVI MINIMAL SYSTEM

*** Warning, this is hardly alpha status !
*** Do not expect the executable part to be ready (you can browse
*** around do "ls" and start the dlt-daemon but that's about it
*** There are missing runtime libraries and there's not even D-Bus so
*** don't expect things to actually work. 
*** However compilation/installation can be tested and debugged as of now.

*** It has only been tested on Ubuntu 12.10 and probably 
*** includes some Ubuntuisms...  You have been warned.

INTRO
This is a test project for GENIVI software.  It is not useable as a basis for
an in-vehicle / embedded system.  It is mostly a testbed for compilation and
configuration issues, and will be executable to the extent of running some
basic tests.

Therefore: (design decisions)
 - No cross compilation
 - No fancy frameworks : whatever OE/Yocto is, this is not, (for better 
   and for worse)
 - Goals: 
         - Stay lean and simple
         - Solve things straight-on and with minimal fuss
 - Not Goals: 
         - Doing things "the right way"
         - future-proofing, portability 
         - even readability... but maybe later some work on that
 - Might get out of date (submodules are locked to a commit until a 
   component is explicitly upgraded)
 - Might break any time 
 - ... but can probably be quickly fixed too
 - ... and shouldn't break spontaneously (submodules are locked to a commit)
 - Execution is done directly on your machine in a chrooted shell
   Consequences:
      - it will never support any "embedded" features e.g. layermanager etc.
      - it will probably not prioritize graphical appl., browsers etc.
      - no booting of kernel/init, at least now (see GLASS ELEVATOR)
      - is useful for testing infrastructure components primarily.
      - On the other hand it will also not clobber your host standard paths
        with the built components.
      - and doesn't require root for any build/install steps (only 
        starting a chroot)

FEATURES
 - A single project git tree that pulls in components as submodules
   (non-git component has a download script instead)
 - Small and simple Bourne-shell build scripts, one per component
 - Separate patch directory, as opposed to cloning and changing components
   N.B.:   Patching is necessary to make this build even
           work(!) So please look at these and either bring upstream or tell 
           me I'm stupid. (There are only 2 options here...)
 - Busybox commandline, so that you have a shell, can move around and try
   stuff.  Configure it at build time - by default it uses defconfig which
   includes most common tools.

INSTALL/HOWTO
 - Clone the GMS project
 - Install host build deps that you know of (gcc/g++, build_essential,
   glib, gio, libgcrypt, dbus etc.)
   There are quite a few others, you might find info in the component docs.
 - Run scripts/init.sh to pull source code into submodules and apply
   patches
 - Then try scripts/build-xxx one by one, or build-all.sh
   Look at "build-all.sh" to see the required build order, or you will have
   unnecessary failures because of that.
 - Look at the failures and install missing build deps. Repeat.
 - Run scripts/start_chroot.sh (also done by build-all).

TODOs 
 - Finish it.  Make it useable.  Actually try the binaries to see what runtime
   deps are missing... So far very little runs. There are missing libraries
   etc...
 - Add more GENIVI components
 - Implement an application that uses Lifecycle
 - Implement an application that uses Persistence
 - Configure and use a node state machine
 - Make use of systemd if possible even if it is not the init process
 - Test build system on a clean host and document needed build deps
 - Maybe put a copy of Itzam code in github to get uniform handling 
   (or leach off Baserock repos that do exactly that ;-)  But it works
   for now.

GLASS ELEVATOR (i.e. "wish list" features that may never see the light of day)
 - Automatic download of all host build deps
 - Support multiple host distros out of the box
 - Shrink target, live up to the Minimal name.  (Some components install docs
   and such useless crap in the target root fs. This gives embedded engineers
   nightmares)
 - Submit GMS as a compliant distro, because if it passes it surely identifies 
   something wrong in the compliance process ;-)
 - Run using LXC instead of chroot.  (But in its current state I think there
   would be no practical difference)
 - Add kernel+systemd init and run virtualized with KVM tool or in QEMU. 
 - AF_BUS, if previous point is ever done

BUGS AND SUCH
 - Lots, in the form of things that are not finished and simply
   have not even been tried yet.  Most obviously, D-Bus not yet
   running.
 - If submodules don't init and fetch fully on the first try, the git tree can
   be in a very confus{ed,ing} state that is tough to get out of.  But that's
   not my bug, imho.  Start clean if you run into this.
 - Untested on other host distros.  Probably has some Ubuntuisms...

LICENSE
Components have their respective licenses and copyright holders as
indicated in their source trees.
Scripts and additions, for now:
(C) 2013 Gunnar Andersson
Creative Commons Attribution Sharealike 3.0
(http://creativecommons.org/licenses/by-sa/3.0/)