On Wednesday, April 27, 2016 9:41:04 AM CDT Colin Walters wrote:
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 armGot 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}" ```
yum and dnf use $basearch I would probably advoate for that. just for consistency. I would think we want the basearch there i386, armhfp, x86_64, ppc64, etc instead of i686, armv7hl, x86_64, ppc64, etc
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)
I was just going by what we have in pungi but a use case could be as you describe with --product being fedora, rhel, mageia and --variant could be atomic-host, router, storage-server, dns-server, workstation, etc the idea being that we have something that provides the pieces of the ref that ostree combines to make the ref. They could be in the json file and not cli arguments.
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
I think comps would be the better way to deal with it. Dennis
Attachment:
signature.asc
Description: This is a digitally signed message part.