On 16/04/2025 07:15, Fabian Arrotin wrote:
> On 09/04/2025 20:52, Peter Georg wrote:
>> 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.
>>
>
> I'd like to answer ticket https://pagure.io/centos-infra/issue/1635 and
> with a solution but still have hard time understanding what's the
> consensus from SIGs themselves.
> If no other reaction I intend to implement the following thing :
>
> - add s390x arch to c9s/c10s extras-common build tags
> - noarch pkgs will land in s390x too (like for other architectures)
> - SIGs can then opt-in to just make their centos-release-<name> pkg a
> arch dependent pkg (and they can untag-build previous noarch pkg to
> remove any confusion)
>
> PS: the noarch situation is already an issue for some SIGs not building
> for all architectures : for example Hyperscale only builds for x86_64
> and aarch64 but a ppc64le user (if any ? ) can already "dnf install
> centos-release-hyperscale" and then encounter issue as there is no
> content built for such arch

Just to let all SIG know that I just implemented what was described
above (as there was no reaction/discussion in the thread after)

--
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]

_______________________________________________
devel mailing list -- devel@lists.centos.org
To unsubscribe send an email to devel-leave@lists.centos.org