Re: OSTree and OCI images

[Colin Walters <walters verbum org>]

On Wed, Nov 30, 2016, at 03:23 PM, Alexander Larsson wrote:
> Oh, no, we can't change *everything* just because we ship things
> differently. It'll just be exactly the same files in the tarballs as
> would be in the ostree commit. So something like:

So you'd have OCI images with the flatpak /app prefix?
Would these have OCI parents?

This case feels really weird since the build process seems like
it has to be flatpak-specific, we're really only using OCI as
a wrapper.  In practice we'd probably expect these images
are generated by something that runs flatpak-builder right?
I guess of course if one had a deb/rpm -> OCI process, in theory
it could be tweaked to rebuild the packages with --prefix=/app,
but then you're not using the default RPMs.

Anyways that seems OK - except I'd give this case its own name.  Like
"flatpakapp-OCI" or something.  It seems distinct from the generic
OCI handling that the atomic command wants.  Obviously there's
a lot of overlapping code.

> But, what do you expect to happen if we try to import a multi-layer
> OCI image (i.e. one that wasn't created by an export). Should we just
> fail because its in the wrong format? 

I think my vote is yes, to start - if flatpak doesn't need it, and I'm
uncertain about reworking the atomic command right now for this.

> Or should we create multiple
> commits, one for each branch, and then some special kind of commit that
> ties these together? How would a user then know how to check out such a
> ref? Does he have to parse the OCI json and do the mapping to the other
> branch names for the layers? 

This is all stuff the atomic command does now.  So it's about potentially
lowering that, but it's a big task and API surface.  Let's start smaller?