handle 'BuildArch: noarch' packages

[fedora-copr-github-bot]

Original issue: https://pagure.io/copr/copr/issue/972 Opened: 2019-08-29 20:41:07 Opened by: praiskup

It is wasting of time to build such packages on all architectures, it should be fine to pick any architecture (say for rawhide), and put the results into all chroot repositories (also for rawhide). Those RPMs can be actually hardlinked, since they will by 1:1 the same.

---

iucar commented at 2019-08-30 08:45:51:

Not necessarily. What about dependencies? Maybe it should, e.g., fail up to F30 because there is some dependency that was introduced in F31. You could end up with a broken package without noticing.

---

praiskup commented at 2019-08-30 09:04:31:

We can not cross the borders of particular fedora version (e.g. F30, vs F31) of course, but fedora-30-x86_64 can inherit builds from fedora-30-i386. That's what is happening in Koji.

[praiskup]

Triage time: this seems like a opt-out feature, because some users might keep different versions of the noarch packages in each repository. But still a worth implementing for performance reasons.

[praiskup]

The other perspective: Some projects plan to ship only noarch packages, and they want to have dnf copr enable working on all architectures. In this sense, somewhat complementary request would be to allow users to have just one architecture chroot enabled for doing builds (e.g. fedora-rawhide-x86_64) but making dnf copr enable work for all architectures without complaining:

DNF4 use-case is totally broken (we install repo files with $basearch in baseurls. But also DNF5 (on aarch64) is sub-optimal:

[root@40342b28520c /]# dnf copr enable owner/project
 https://hostname/api_3/rpmrepo/owner/project/fedora-39/                                                                                                                                                                                                                                                                                                                    100% | 109.0   B/s | 899.0   B |  00m08sChroot not found in the given Copr project (fedora-39-aarch64).
You can choose one of the avaiable chroots explicitly:
 epel-6-x86_64
 epel-7-x86_64
 epel-8-x86_64
 epel-9-x86_64
 fedora-26-x86_64
 fedora-27-x86_64
 fedora-28-x86_64
 fedora-29-x86_64
 fedora-30-x86_64
 fedora-31-x86_64
 fedora-32-x86_64
 fedora-33-x86_64
 fedora-34-x86_64
 fedora-35-x86_64
 fedora-36-x86_64
 fedora-37-x86_64
 fedora-38-x86_64
 fedora-rawhide-x86_64

It would be just OK to enable fedora-rawhide-x86_64, if copr maintainer decides so.

[praiskup]

Requested by @lzaoral recently, we moved this into the "low prio" category for now. If you disagree, please raise your voice.

[praiskup]

Some IRC discussion from #fedora-devel:

<pbrobinson> mhroncok: by chance do you know who owns https://copr.fedorainfracloud.org/coprs/g/copr/PyPI/ ?
<praiskup> I think ksurma @befeleme on GH
<mhroncok> pbrobinson: the copr team owns it and @ksurma is building stuff there I guess
<pbrobinson> mhroncok: @ksurm can we turn on aarch64 or potentially all the Fedora arches?
<jsbillings> the flocktofedora.org issue apparently is related to this issue: https://pagure.io/fedora-infrastructure/issue/11421
<mhroncok> pbrobinson: I'll tell @ksurma you asked, but you might better send an email, she's not here
<mhroncok> pbrobinson: but technically, I think that the current code of pyp2spec only supports pure Python packages, so the repo is all noarch
<pbrobinson> mhroncok: sure, I get the noarch bit, but adding the copr using the usual commands fail and there appears to be some that aren't noarch
<mhroncok> so unless you are interested in "does this pure Python package build on aarch64 when I don't actually run any tests" I don't see much benefit
<mhroncok> ah, I didn't know about the no-noarch ones, maybe my info is outdated
<pbrobinson> mhroncok: the benefit is easy consumption by users
<mhroncok> I see -- I considered the entire thing an experiment -- whoever consumes this copr as an user is asking for trouble
<praiskup> FTR, I was arguing with msuchy that we should do https://github.com/fedora-copr/copr/issues/972 yesterday
<mhroncok> adding more architectures will double/tripple/quadruple the energy wasted to produce more or less the same repo with different architecture in its URL
* ASLDC-worker-386 (~ASLDC-wor@62.33.231.102) has joined
<mhroncok> praiskup++
<mhroncok> alternatively add a way to mark an entire project as noarch, and make copr enable work on all arches ofr such porject 
* mhroncok goes back offline, we are at EuroPython
<praiskup> pbrobinson, if that matters, 'dnf5 copr enable project CHROOT' command should do the correct thing (on rawhide you need https://github.com/rpm-software-management/dnf5/pull/744 though which is in https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-unstable/)
<praiskup> with dnf4, repo file with '$basearch' is installed no matter what you put in CHROOT :-(
* wtay odešel (Ping timeout: 252 seconds)
<praiskup> what are the non-noarch packages actually, do you have any example?
<pbrobinson> praiskup: I would sooner have it just work in the usual way because there's a lot of users that expect things to "just work normally" on aarch64

[praiskup]

Note that dnf-3 copr enable PyPI fedora-rawhide-x86_64 installs repofile with baseurl containing fedora-rawhide-$basearch , so cross-arch use-case is non-working. With dnf5 copr enable this is no longer the case`.