#75 f41: add bootc-tier0 to variants
Merged a month ago by miabbott. Opened a month ago by pwhalen.
fedora-iot/ pwhalen/pungi-iot missed-variant  into  main

f41: add bootc-tier0 to variants
Paul Whalen • a month ago  
file modified
+5
@@ -12,5 +12,10 @@ 

              <arch>aarch64</arch>

              <arch>x86_64</arch>

          </arches>

+     <variant id="bootc-tier0" name="bootc-tier0" type="variant" is_empty="true">

+         <arches>

+             <arch>aarch64</arch>

+             <arch>x86_64</arch>

+         </arches>

      </variant>

  </variants>

Add bootc-tier0 image to variants file.
Signed-off-by: Paul Whalen pwhalen@fedoraproject.org

Pull-Request has been merged by miabbott

a month ago

NAK, this isn't another variant, IMO it's just a different deliverable to the bootc variant. We, as in Fedora, delivers a bunch of different artifacts for say IoT (raw, simplified provisioning, iso, etc) without new variants, we need to look at why tier0 is failing and fix the pungi config so it fits into bootc variant.

This is merged now, lets run and clean it up with a followup PR.

One unrelated problem here is that right now because there's only one container image, the "tier" nomenclature isn't exposed. I was never happy with calling it "tier", but naming is hard. Perhaps "minimal"?

Another very important thing I want to mention is we've gotten some pushing to use comps - and that could make a lot of sense going forward potentially too.

Right now using comps is a bit tricky with rpm-ostree, but very doable with the dnf-based builder.

One unrelated problem here is that right now because there's only one container image, the "tier" nomenclature isn't exposed. I was never happy with calling it "tier", but naming is hard. Perhaps "minimal"?

Perhaps that's a discussion that should happen on the upstream repo?

Another very important thing I want to mention is we've gotten some pushing to use comps - and that could make a lot of sense going forward potentially too.

Right now using comps is a bit tricky with rpm-ostree, but very doable with the dnf-based builder.

Again upstream repo discussion, maybe we need a tracker in upstream https://gitlab.com/fedora/bootc/base-images linking to the issues so we can track them there and know when we can revert hacks or change to to fixed best practice from upstream.

Perhaps that's a discussion that should happen on the upstream repo?

Definitely yes.

Metadata