How do image-based systems figure out what partition sizes they need?

Not necessarily.

Basically the composefs git repository is a low level unopinionated generic tool. Yes, `mkcomposefs` can write files into the object store, but so can any other tool and in practice we expect sophisticated higher level software to do exactly that.

> And the EROFS images can only work if the content store in place, happens to contain all the content that was there when the image was created in the first place?

Well yes, you are responsible for ensuring the object store is populated. But for example you could totally have higher level software, before invoking "mount.composefs" quickly check that the expected objects are there, and if not fetch them from a network object store on-demand. There's CLI tools and a C library that lets you read and write the composefs EROFS for doing things like this.

> And how would garbage collection in the content store work?

That is again up to higher level tooling; I'll try to fill out the docs more but the simple baseline is:

- You maintain a set of "GC roots" (images) that are composefs blobs
- Iterate over those composefs blobs, parse them to find which objects they reference
- Iterate over the object store and remove unreferenced objects

We are working on a higher level Rust project that will be a much more opinionated interface to things like this, including direct integration with e.g. OCI.

But there are already others who have integrated composefs, e.g. there was a lightning talk at All Systems Go from https://rauc.io/ about using composefs.