[OE-core] OSTree as an output target for OE

[Colin Walters]

...is something I'd love to see.  I don't have much time in the
immediate future to work on it myself, but I'd just like to raise the
visibility of the project here because I am very much keeping in mind
the needs of embedded systems.  Or at least what I perceive them to be;
my job is not embedded, even though I use OE for a project.

In particular I know that while historically many embedded devices
aren't Internet connected, that's changing (which is a good and bad
thing).  But if your device will have the ability to upgrade itself
online, OSTree offers a model for completely atomic upgrades, which I
imagine is quite desirable for many unattended devices.

Here's a link to the LWN article:
http://lwn.net/Articles/564793/
Which links to my blog, but the most relevant thing here will probably
be:
https://people.gnome.org/~walters/ostree/doc/


Many of the changes it asks for:
https://people.gnome.org/~walters/ostree/doc/adapting-existing.html
are somewhat nontrivial from the current OE-core; but on the other hand,
it's not *that* far away.

The biggest technical change is having a new rootfs backend; I have a
truly hideous, hacky implementation here:
https://github.com/cgwalters/poky/blob/gnomeostree-3.10-dylan/meta-gnomeos/classes/gnomeos-contents.bbclass
which includes doing UsrMove (and further, unifying bin/sbin) etc. which
then generates two tarballs out of the OE content.  From there, I take
those two tarballs and commit it into an OSTree repository:

https://git.gnome.org/browse/gnome-ostree/tree/src/js/tasks/task-build.js?id=600ea8e70cf8c8bf56a79ad5ec39c122f9066a92#n1125

Then on the client side, users can choose between the refs
"gnome-ostree/buildmaster/x86_64-runtime" and
"gnome-ostree/buildmaster/x86_64-devel-debug" where the first is a
runtime system with no debuginfo, and -devel-debug has all of the
developer tools (gcc, make, etc.) and *all* of the debuginfo.

So you can see here the client machine can (relatively efficiently)
switch trees; it's not like images where you are locked into one thing.
It's also not like packages where you have a combinatorial explosion of
options.