If a package separates different source files for different arches, how can copr build different srpms?

Ask Fedora
1

I use and maintain a package named anki. It is really hard to build. Currently my packaging efforts are limited to repackaging the upstream-published python wheels available from pypi. In addition, building the package offline from source with minimal patches and minimal vendoring is under my radar, but limited by time and resources.

I provide packages for both x86_64 and aarch64 architectures. These have different python wheels in pypi. When I upload the spec to copr, it creates 1 srpm and uploads that to all builders. The builds of that srpm succeeds in 1 architecture and fails in the other. As a result, I currently upload 2 different srpms for the 2 arches. Is there a way where I can only upload the spec file and it will fetch appropriate sources for different arches and package them?

2

It sounds like should work from the sources of the project and not the PyPI artifacts.

I assume you know that https://apps.ankiweb.net/ is where the PyPI anki pages point off to
and that on that page there is a download link for linux to get a tarball.

I did not look at the tarball, but maybe that provides you with sources you can use to package anki.

3

That’s just a prebuilt package for x86_64 architecture with bundled Qt, python and other stuff. For aarch64, upstream recommends using the python wheels from PyPI. Source code in github requires things not packaged in Fedora yet, like yarn, some unpackaged rust crates, some nodejs libraries and other stuff. Getting those packaged requires liaison with Rust SIG and other parties, as it is very difficult for a single individual.

Currently I already maintain ~60 other packages in my coprs across EPEL and Fedora. Tracking upstream releases, patching those for offline builds, vendoring unpackaged dependencies and packaging the whole thing is a huge undertaking, also one of the probable reasons why anki was orphaned by its maintainers in Fedora. Upstream is hostile to making changes for the ease of packaging in distributions, citing bad experiences from Ubuntu using archaic and pre-release versions in their LTS distributions. Therefore, building from source is not feasible in the current circumstances.

Is there any other way of repackaging the binaries for 2 architectures from a single spec?

4

Add both wheels to Source without using %{_arch}.
Address the correct wheel in %prep by %{_arch}.

2 Likes