Re: ostree multiarch support

[Colin Walters <walters verbum org>]

Based on the title I thought this was going to be something like including
i686 and x86_64 content in the same ostree commit and what the branch
name should be.  Or perhaps more interesting the scenario where one
has fully 32 bit userspace but a 64 bit kernel.  Or even x32.

But anyways that's a topic for another day...

On Tue, Apr 26, 2016, at 06:00 PM, Dennis Gilmore wrote:

> So I am trying to figure out how from a release engineering perspective ostree 
> and rpm-ostree are supposed to handle multiarch support.  take teh atomic host 
> json file I ahd to make the following changes to make it work on arm

Got it.

> --- a/fedora-atomic-docker-host.json
> +++ b/fedora-atomic-docker-host.json
> @@ -1,5 +1,5 @@
>  {
> -    "ref": "fedora-atomic/rawhide/x86_64/docker-host",
> +    "ref": "fedora-atomic/rawhide/armhfp/docker-host",

This one is kind of related to:
https://github.com/projectatomic/rpm-ostree/issues/236

In that if we did start handling releasever substitution, we
could pretty easily handle arch subtitution as well.

A messy aspect to this is introducing subtitution when none
existed before is a bit of a backwards compat break in theory...
but in practice I bet we could say:

```
    "ref": "fedora-blah/${arch}"
```

because the `$` character is illegal in refs.
  
>      "repos": ["fedora-rawhide"],
>  
> @@ -31,8 +31,7 @@
>                  "rpm-ostree", "lvm2",
>                  "authconfig",
>                  "btrfs-progs", "e2fsprogs", "xfsprogs",
> -                "grub2", "grub2-efi", "ostree-grub2",
> -                "efibootmgr", "shim",
> +                "extlinux-bootloader",
>                  "gnupg2",
>                  "basesystem",
>                  "python",

This one is harder...

> To me the ref has two possible solutions, one we use a variable like we do for 
> urls in yum/dnf  or two we have the different parts of the ref as arguments 
> and the arch is added automatically.  something like "--product fedora-atomic 
> --release rawhide --variant docker-host"

Not sure about `--variant`...that sounds like different treefiles if you're thinking
of things like "workstation", "router" etc.  Right?  (Potentially inheriting
from a base)

> the packages could have arch specific sections 
>
> "x86_64-packages": [ "ostree-grub2", "grub2", "grub2-efi", "shim", 
> "efibootmgr"]

This wouldn't be too hard, but...
 
> or we can move to comps groups and have non mandatory packages for the 
> bootloaders, etc that are arch specifc. 

This came up earlier:
https://mail.gnome.org/archives/ostree-list/2016-April/msg00010.html

It sounds like handling comps would be the most compatible
solution to this in that other software like Anaconda already uses them
too for this purpose.  It's mostly that libhif doesn't support them for
semi-historical reasons. I filed:
https://github.com/rpm-software-management/libhif/issues/107