Re: extensions like xdg-app

[Colin Walters <walters verbum org>]

On Fri, Feb 26, 2016, at 06:36 PM, Robert McQueen wrote:

> In ARM devices as a co-incidence of uboot having the kernel it looks for 
> in a config file kept outside of the OStree, 

See also https://github.com/GNOME/ostree/pull/156

> However on PC devices the kernel is selected by the ostree root, as it 
> should be - but as we get newer kernels/GL/mesa/etc for newer PCs the 
> chance of regression on old ones goes up and we need to go back and test 
> them. We can hold back certain hardware on certain OS releases but that 
> sucks because then they don't get the new shineys.
>
> So a mechanism to put certain systems on a fixed kernel/X/GL version but 
> update the rest of the system would be pretty rad - or vice versa - 
> parachute new kernel/X/mesa in from the future but not have to upset the 
> OS applecart.

There's two different ways to do this.  First, have different trees on the server side.
If you're doing something like GContinuous (or future rpm-ostree) are where
individual components/packages are stored as commits and unioned, it's
pretty cheap to have multiple.

GContinuous today has -runtime and -devel-debug, there's no reason one
couldn't have 10s of different trees per hardware.

A slight trick to this is if one is introducing it after the fact, how do you get
clients to switch?  I could imagine two approaches:

1) Metadata in the commit object that says "this branch is EOL, switch to this other one"
    I'd love to see this implemented.
2) Having the client send some sort of hardware identifier in the first HTTP request, like
    Anaconda supports with kickstart, then the server uses that to reference the content.

The second major approach, and gets to more what you were thinking, is that
you compute the union of trees on the client.  This would not be really hard to do,
although I thought you were originally just talking about the kernel, which is
often kept distinct from userspace.

So here on the server side you'd have:

exampleos/x86_64/${hardwarename}/kernel
exampleos/x86_64/userspace

Then we'd have the origin file say something like:

[origin]
refspec_union=exampleos/x86_64/classic/kernel;exampleos/x86_64/userspace

And the client would do the union.  This wouldn't be very hard to write;
If you look at the checkout_deployment_tree() function, it'd just be
doing multiple ostree_repo_checkout_tree_at() with OSTREE_REPO_CHECKOUT_OVERWRITE_UNION_FILES.

If you're also talking about having different userspace components like X and GL...
it seems you'd need to carefully coordinate updates between the different
trees...which leads a bit towards having a concept of dependencies.

The original concept was that OSTree will never have dependencies in the core...the intention
is that people write things like:
https://github.com/projectatomic/rpm-ostree/pull/107
Basically, RPM is a crappy tool for writing to the filesystem, but particularly
with libsolv it's great at handling dependencies.  OSTree is a better tool
for filesystem management, but I don't want to maintain another package system
myself.

> So the question is - could you do something similar to xdg-app 
> extensions for ostree to make a kinda "hwpack" which could be upgraded 
> separately to the OS?

The big picture answer is yes - there's lots of ways to do this, and OSTree
is intentionally really flexible.  In particular I'd like to enhance client-side tooling,
as it's pretty important for the "just hack on something for development" case.