distrodefs: Include default firmware packages only when not Oracle Linux 10

[fwiko]

Fix a dependency resolution failure when building image-installer and network-installer image-types for Oracle Linux 10.

After success using image-builder to create OL9 images, we failed to replicate our workflow for OL10 because distrodefs/rhel-10/imagetypes.yaml specifies the following firmware packages for the x86_64_installer_platform and aarch64_installer_platform platform definitions by default:

• amd-gpu-firmware
• amd-ucode-firmware
• atheros-firmware
• brcmfmac-firmware
• intel-gpu-firmware
• iwlegacy-firmware
• iwlwifi-dvm-firmware
• iwlwifi-mvm-firmware
• libertas-firmware
• mt7xxx-firmware
• nvidia-gpu-firmware
• nxpwireless-firmware
• realtek-firmware
• tiwilink-firmware

The Oracle Linux 10 Release Notes specify these 14 packages were removed from the AppStream and/or BaseOS repos.

This change isolates the upstream EL10 split hardware firmware packages and conditionally opts into them only when the target distribution is not Oracle Linux.

[supakeen]

Hey this is fine, but there's a few things I'd like to do differently.

First organization wise:

1. Let's define this package set as a single anchor under .common; and call it something like installer_split_firmware_pkgset and then reference it. It's duplicated multiple times now (it already was, but if we're changing it let's do this as well to make our lives easier in the future and a bit easier to read the diff). If you want you can also put the entire condition as an anchor.
2. The same package set is also duplicated in the ppc64le platform so it can be removed there as well.
3. The installer_split_firmware_pkgset should also be included under the os package set for the image-installer which is defined in the bare_metal_pkgset.

Then it also affects more artifacts than it should:

1. s390x doesn't have the firmware package set but the new conditions don't exclude it.
2. There's no not_arch condition; let's add it and then use it in the split firmware conditions so it's a bit easier to deal with. I've opened a PR to add it: #2621 so you can rebase after that lands and then use it 🙂.
3. I noticed that we don't refer to the correct platform on aarch64 so I have an open PR to address that as well: #2622.

After rebasing on both #2621 and #2622 (after they land) and with the organization fixes this should be much better.

The easiest way to find these things and see if they're affecting artifacts they shouldn't is to run the ./tools/gen-manifest-checksums.sh which will generate checksums for the manifests that we test in CI (which doesn't include OL, but does include RHEL). If everything goes right it should introduce no changes.

I've applied my suggestions locally (and incorporated those two PRs) and then it leads to no checksum problems so we should be good soon.

---

Don't address these concerns immediately, perhaps other reviewers have other ideas about the organization of this.

[fwiko]

I've consolidated the pkgset and condition for reuse with the not_arch option and removed the ppc64le platform. Although there are no OL10 distributions for Power PC, image/network-installer builds for supported ppc el10 distributions should have these split packages added by the condition.

I've also noticed the minimal-tar-xz image-type has a subset of the firmware packages hardcoded, do we want to continue on this abstraction path and split the list of firmware packages into categories that would allow a conditions to combine subsets, remove the default, or add a specific condition?

[achilleas-k]

Can you rebase the branch and drop the merge commit? We use a fully linear history here.

[achilleas-k]

This commit isn't doing what it's supposed to. I'm seeing a lot of changes in the package selection for RHEL 10 and CentOS 10 images. The packages seem to have been dropped from the image-installer for x86_64 and ppc64le and at the same time added to the network installer for ppc64le and s390x.