Re: OSTree and OCI images

[Alexander Larsson <alexl redhat com>]

On fre, 2016-12-02 at 10:48 -0500, Colin Walters wrote:
> 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?

You'd have two OCI images, one for the runtime and one for the flatpak
runtime, and the app one would have apps build in /app, yeah.

> 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.

If you use flatpak-builder, then these would be initially commited to
an OSTree repo and exported from there to an OCI image. But yes, i
imagine than many will be created in other ways, for instance rpm-
ostree + a post-process script that moves /app to /files and adds a
/metadata file.

And yes, these would not be default built RPMs, but once build in a
different environment where it gets an /app prefix.

> 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.

Well, its just using the OCI format to transport data, rather than an
directly usable container image. This seems like something other people
are looking at doing too.

> > 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.

I guess I can merge layers manually in flatpak if needed then. Its
really a very corner case that shouldn't happen in typical use.

> > 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?

Sure. I've already started on the basics. Will have something working
next week.


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's a leather-clad zombie stage actor with acid for blood. She's a 
virginal belly-dancing bodyguard from Mars. They fight crime!