While working on the new errata implementation, I noticed that noarch packages are being treated as arch packages when it comes to oval data generation.

As you can see, flatpak-selinux is a noarch package but is being considered as an arch one. Let's take a look in db:

• NewErrataPackages table:

 flatpak-selinux        | 1.12.9  | 3.el8_10 |     0 | aarch64 | flatpak
 flatpak-selinux        | 1.12.9  | 3.el8_10 |     0 | ppc64le | flatpak
 flatpak-selinux        | 1.12.9  | 3.el8_10 |     0 | s390x   | flatpak
 flatpak-selinux        | 1.12.9  | 3.el8_10 |     0 | x86_64  | flatpak

• NewErrataToAlbsPAckages table:

flatpak-selinux        | noarch  | 1.12.9  | 3.el8_10 |     0
flatpak-selinux        | noarch  | 1.12.9  | 3.el8_10 |     0
flatpak-selinux        | noarch  | 1.12.9  | 3.el8_10 |     0
flatpak-selinux        | noarch  | 1.12.9  | 3.el8_10 |     0

Actually, this is not a problem as pulp update record packages are getting the right arch and oval does not indicate the architecture of pkgs. This was the way to go when taking data out of RHEL's OVAL streams, because architectures are not mentioned in packages objects. It is somehow reflected in states but there's no way to figure out the architecture of a package, and for this reason, we've been adding noarch as arch packages for every supported architecture.

This involves a tiny update of the albs-web-server's load_platform_packages method and a small tweak in frontend to show noarch errata packages, as right now it only shows packages that belong to the platform's supported architectures