RHEL 8 ticket: https://bugzilla.redhat.com/show_bug.cgi?id=2125335

edk2-aarch64 is already shipped in AppStream repos, however, note it is only shipped on aarch64 hosts, since RHEL only supports KVM and thus doesn't need the firmware on non-native archs.

Would it be possible to ship edk2-aarch64 in AppStream for all architectures? As things stand, we have a bit of a conundrum, as we probably can't ship it via a -epel package as it would create a conflict (see https://src.fedoraproject.org/rpms/edk2-epel/pull-request/1 for a PoC of that approach), but we also can't gate it (as it's a noarch package). Based on the discussion in https://bugzilla.redhat.com/show_bug.cgi?id=2125333 I suspect SLOF might have a similar issue.

To summarize the discussion in #epel on this: edk2 is ExclusiveArch: x86_64 aarch64; the edk2-aarch64 subpackage is BuildArch: noarch and it gated to aarch64 only (via an %ifarch, for both the package and its build). This makes all known options to workaround this not tenable:
- we can't make it not shipped on aarch64 in EPEL, as it's a noarch package
- we can't make it arched and gate it out of aarch64, as it only builds on aarch64, so no package would be provided for x86_64 (plus, making this arched has the potential of causing other issues down the road)

The only option left is to either get this added to AppStream in EPEL for all arches, or to somehow gate it out of EPEL composes for noarch within the releng pipeline (I have no idea whether that's even possible though).

For clarity, the last sentence in the previous comment should read "The only option left is to either get this added to AppStream in RHEL for all arches"

(In reply to Davide Cavalca from comment #3)
> Would it be possible to ship edk2-aarch64 in AppStream for all
> architectures? As things stand, we have a bit of a conundrum, as we probably
> can't ship it via a -epel package as it would create a conflict (see
> https://src.fedoraproject.org/rpms/edk2-epel/pull-request/1 for a PoC of
> that approach), but we also can't gate it (as it's a noarch package). Based
> on the discussion in https://bugzilla.redhat.com/show_bug.cgi?id=2125333 I
> suspect SLOF might have a similar issue.

This isn't a formal answer, but I think it is unlikely RHEL would be willing to ship edk2-aarch64 in AppStream for all archictures, because of the support criteria associated with shipping something in that channel. I think it would have to be in CRB to make it clear it is an unsupported deliverable on the arches, but I'm not sure if it is possible to have a package in AppStream on 1 arch, and CRB on all other arches.

Presumably there might also be a need for 'edk2-ovmf' to be shipped on non-x86_64 arches too for parity (it only ships in AppStream on x86_64 platforms), which will face the same problems.

(In reply to Davide Cavalca from comment #0)
> edk2-aarch64 and edk2-tools are currently unshipped packages. I'd like to
> request them to be added to CRB so that they can be made available in future
> releases.

Is there more to it. What's the justification for shipping those packages. And why CRB repo.

> Is there more to it. What's the justification for shipping those packages. And why CRB repo.

There's work in https://bugzilla.redhat.com/show_bug.cgi?id=1995353 to build qemu in EPEL 8, which would require these packages being available. The CentOS Hyperscale SIG is also working on updated qemu packaging (as an incubator for the work that will eventually be incorporated in that BZ), and that requires these packages. See https://src.fedoraproject.org/rpms/qemu/pull-request/28#comment-115808 for some more details on that effort.

Specifically: we need -ovmf and -aarch64 on all arches for qemu packages to be installable, and be need -tools as a BR to be able to rebuild ipxe-roms (among other things). As for why CRB: because that's usually where unshipped packaged get added per policy (https://wiki.centos.org/FAQ/CentOS8/UnshippedPackages); I would also be fine having these in AppStream.

(In reply to Daniel Berrangé from comment #6)
> This isn't a formal answer, but I think it is unlikely RHEL would be willing
> to ship edk2-aarch64 in AppStream for all architectures, because of the
> support criteria associated with shipping something in that channel. I think
> it would have to be in CRB to make it clear it is an unsupported deliverable
> on the arches, but I'm not sure if it is possible to have a package in
> AppStream on 1 arch, and CRB on all other arches.

I've raised this internally and have got confirmation that it IS possible to
have a package shipped in AppStream on 1 arch and CRB on other arches, so
that is not a blocking problem in making a decision whether to support
this request.

Created jira request for this change: https://issues.redhat.com/browse/RHELCMP-10007

This is available in CentOS Stream now.

Packages are part of RHEL composes too now.

This is now fixed in the RHEL-9.2.0-20221023.0 or newer composes.

Check the related packages in the RHEL-9.2.0-20221023.0 compose, all work as expected. So set status to VERIFIED.


Details:

1. For x86_64 platform:
edk2-ovmf in AppStream repo,
http://download.eng.pek2.redhat.com/rhel-9/composes/RHEL-9/RHEL-9.2.0-20221023.0/compose/AppStream/x86_64/os/Packages/

edk2-aarch64 and edk2-tools in CRB repo,
http://download.eng.pek2.redhat.com/rhel-9/composes/RHEL-9/RHEL-9.2.0-20221023.0/compose/CRB/x86_64/os/Packages/edk2-aarch64-20220826gitba0e0e4c6a-1.el9.noarch.rpm
http://download.eng.pek2.redhat.com/rhel-9/composes/RHEL-9/RHEL-9.2.0-20221023.0/compose/CRB/x86_64/os/Packages/edk2-tools-20220826gitba0e0e4c6a-1.el9.x86_64.rpm
http://download.eng.pek2.redhat.com/rhel-9/composes/RHEL-9/RHEL-9.2.0-20221023.0/compose/CRB/x86_64/os/Packages/edk2-tools-doc-20220826gitba0e0e4c6a-1.el9.noarch.rpm


2. For aarch64 platform:
edk2-aarch64 in AppStream repo,
http://download.eng.pek2.redhat.com/rhel-9/composes/RHEL-9/RHEL-9.2.0-20221023.0/compose/AppStream/aarch64/os/Packages/edk2-aarch64-20220826gitba0e0e4c6a-1.el9.noarch.rpm

edk2-ovmf and edk2-tools in CRB repo,
http://download.eng.pek2.redhat.com/rhel-9/composes/RHEL-9/RHEL-9.2.0-20221023.0/compose/CRB/aarch64/os/Packages/edk2-ovmf-20220826gitba0e0e4c6a-1.el9.noarch.rpm
http://download.eng.pek2.redhat.com/rhel-9/composes/RHEL-9/RHEL-9.2.0-20221023.0/compose/CRB/aarch64/os/Packages/edk2-tools-20220826gitba0e0e4c6a-1.el9.aarch64.rpm
http://download.eng.pek2.redhat.com/rhel-9/composes/RHEL-9/RHEL-9.2.0-20221023.0/compose/CRB/aarch64/os/Packages/edk2-tools-doc-20220826gitba0e0e4c6a-1.el9.noarch.rpm


3. install the packages successfully.
# yum install edk2-*

====================================================================================================
 Package                  Arch       Version                         Repository                Size
====================================================================================================
Installing:
 edk2-aarch64             noarch     20220826gitba0e0e4c6a-1.el9     beaker-CRB               5.3 M
 edk2-debugsource         x86_64     20220826gitba0e0e4c6a-1.el9     beaker-CRB-debuginfo     411 k
 edk2-ovmf                noarch     20220826gitba0e0e4c6a-1.el9     beaker-AppStream         4.3 M
 edk2-tools               x86_64     20220826gitba0e0e4c6a-1.el9     beaker-CRB               421 k
 edk2-tools-debuginfo     x86_64     20220826gitba0e0e4c6a-1.el9     beaker-CRB-debuginfo     1.2 M
 edk2-tools-doc           noarch     20220826gitba0e0e4c6a-1.el9     beaker-CRB                89 k

Transaction Summary
====================================================================================================
Install  6 Packages

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Important: edk2 security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2023:2165