The "resolve" builtin now does a lot more heavy lifting; we expand the
manifest.json, and "build" consequently is less intelligent now, more
of a low-level implementation.
Store the compose contents as a JSON file in the filesystem tree.
This is more flexible compared to defining "compose" as just a literal
layering of filesystem trees. For example, we might want to run
prelink.
We need to be more formal about where we get patches from, and more
specifically what version. Let's assume they're also stored in a git
repository that we fetch, instead of copying them from "wherever the
manifest is".
This meshes nicely with splitting between manifest.json and
snapshot.json.
Let's have chroot-compile-one be the core logic for composing a
buildroot, etc. This allows us to use it as a developer tool by
checking out a tree, then doing a chroot build.
Expose the lower-level functionality in libostree, change checkout
builtin to be a higher level driver. This will allow us to more
easily improve the "checkout" builtin..
Continuing from 16c0cfe9b5, we now have
the problem that we're removing the executable bit, which obviously
breaks things when we chroot in for a build. Fix this by masking over
our bits.
Otherwise
1) Lots of unnecessary shit happens and I like my straces to be clean
2) There is no dbus session bus for system daemons or when we're run
in a root context
We want to support both "bare" lookups where "foo" can be local, or in
any remote, as well as prefixed ones for a specific remote.
This fixes ostree-pull noticing that nothing has changed.
This should be useful on clients to trim old refs. For example,
after an upgrade the system could do:
ostree --repo=/ostree/repo prune --depth=2 gnomeos-3.4-i686-runtime
This would remote all objects that aren't in the current build and the
previous one.
This totally breaks when the file we're trying to request was already
gzip'd. We don't want to uncompress e.g. man pages because that
breaks content-addressed storage.
Before we were creating randomly-named temporary files in repo/tmp
when downloading via pull, but that means if the download process is
interrupted, we have to redownload everything again.
Let's still keep the concept of a "transaction" where files are
stored in the repository as atomically as possible (i.e. we
do a bunch of rename() calls), but now we also have an explicit
"tmp/pending/objects" directory that contains named objects.
This allows us to then skip redownloading things that are pending.
Colin Walters