Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
One of the important properties of libostree is that it's intended to support every use case covered by package systems (dpkg/rpm/etc) today. Independence of the block layer is critical for this. For example, just like today one can take a set of RPMs and install them on a dm-crypt device, a plain ext4 partition, xfs+lvm, etc - one can do the same with libostree.
The flexibility inherent in being file based is one of the crucial things that allows rpm-ostree to do per-client layering, which in turn helps libostree work both in "single/small-scale" scenarios where one takes a base layer and adds packages per machine, and it also provides atomic updates even for scale out scenarios.
However, on bare metal, and in particular devices where one doesn't want to support extensive configuration (e.g.
I'm not sure offhand how much this would make sense versus a new project that happened to share code (or really, just using the chromeos updater as it exists today).
But could we get to a point where one could take an ostree commit (or a tarball or whatever), and deploy it as either the existing libostree or dm-verity backend? I think the answer is: no, in the sense it doesn't make sense to do per-client. An organization wanting this would need to run a "verity generator server" that took the user's kickstart (partition config) plus ostree, and acted a signing server.
Longer blog on this: https://blog.verbum.org/2017/06/12/on-dm-verity-and-operating-systems/
Basically, I think dm-verity is really only worth it when doing true "appliance" devices, where all of the privileged code is sealed. I'm still not sure what the role of ostree would be here; either on the client or server. As I mentioned in the blog, I could imagine something like taking a Fedora Atomic Host ostree commit, doing some config, adding containers, and then a tool seals all of that up with dm-verity.
But what I am still unclear on is whether it's worth trying to wrap this model with libostree or not vs the chromeos updater.