Re: OSTree and OCI images



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?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]