On 08/04/2025 14.17, Fabian Arrotin wrote:
On 07/04/2025 17:26, Neal Gompa wrote:
On Mon, Apr 7, 2025 at 11:24 AM Troy Dawson via devel devel@lists.centos.org wrote:
Looking beyond s390x, can we have them set by arch in some way.
I'm thinking of the ISA SIG, we currently only have x86_64 packages built, and I didn't even think about our -release file being in other arches. Plus, we're thinking of having SysV (is that the extension?) and wouldn't want others to think we're doing support for other arches.
I guess we (ISA) could have our centos-release-isa rpm NOT be noarch, and specifically set the arch.
Do you mean RISC-V? But also you can just allow the repository to fail if it doesn't exist. Set "skip_if_unavailable=True" in the repo configs. The repositories already are set up to fetch archfully through repo variables.
Just as a summary, it seems we'd have two proposed approaches :
- Troy suggested modifying .spec for centos-release-<name> from
BuildArch: noarch to a list of supported architectures, that would (or not) then be available under https://mirror.stream.centos.org/SIGs/ <stream-release>/extras/<arch>
- Neal proposed instead that can we keep it "noarch" but then .repo from
each SIG centos-release-<name> would need to be modified to ensure that skip_if_unavailable=True would be added, otherwise it would still block users from unsupported architecture if they install a centos-release- <name> pkg that doesn't have pkgs / repository
In all the cases, that would need something to be done. For option 1 I can change the build tag to add 's390x' (actually it only covers x85_64, ppc64le and aarch64 - example for 9s : https://cbs.centos.org/koji/ taginfo?tagID=2556). But if I only do that, the next time a pkg would be tagged, it would then import *all* existing noarch in the s390x repository
What would be the best approach ? I'd like to hear from all SIGs as it's about their packages in their repositories :)
Speaking for the Kmods SIG I'd prefer keeping the centos-release-<name> packages "noarch". However, this means finding some other way to handle this situation. Neal's suggestion to add skip_if_unavailable=True isn't a real solution in my opinion: It would have to be set conditionally only for arches for which no packages are actually provided, which, to my knowledge, isn't possible. Otherwise, it would also suppress any other error about why a repository can't be synchronized. In my opinion, this is an undesirable side effect that should not be underestimated. Another approach would be to always create a repository for every arch even if the arch is not enabled for the particular build target. This approach leads to the creation of unnecessary repositories and could give users the impression that a SIG supports an architecture but the provision of packages is, for example, only delayed, even though this is not the case.
Since I don't know of any sensible approach to solve this problem under the condition of keeping the packages as "noarch", Troy's approach is the most sensible in my opinion. SIGs that support all architectures can of course keep their centos-release-<name> packages as noarch.