Merkle trees and build systems

To get the apt2ostree build rules right to work it needs to know exactly what the inputs and outputs are. I found this difficult to work out with dpkg and apt so I ended up copying the multistrap approach and doing the unpacking and creating the dpkg database myself. In particular with apt I was worried about how the local system configuration of apt would affect the creation of these chroots.

Not running preinst has worked out ok for us so far. I guess because we're never doing `apt upgrade`, we always build a new tree from scratch.

> While many of the hardcoded assumptions might appear to work, perhaps better now that we have been improving the pseudo-essential package set when it comes to installation bootstrapping (see https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap)

This seems like really good news. Thanks for sharing.

> these cannot be generally applied to any package in distributions like Debian (or Ubuntu). Things like not running the preinst, or the bare passwd databases, or only handling a hardcoded list of control files, etc. In any case I guess apt2ostree could already further benefit from some of the things that we have been working on with the installation bootstrap improvements.

I guess it's worked for us because we're not trying to build a box of parts OS like debian, we're building a embedded product, so we know that the thing that we test is the same as what our customers will be using, whereas with Debian you don't know what combination of packages your users will be using.

On the subject of apt2ostree - I think the key innovation in it is apt lockfiles. I talk a bit about it in the README: https://github.com/stb-tester/apt2ostree#lockfiles . This allows us to do all the apt bits, and store the result in source control, then all the dpkg bits that happen during the build should be relatively deterministic. It also means that an apt upgrade is explicit and visible in the source repo for the rootfs image.