You are not logged in.
I've noticed a lot of packages explicitly list i686 and/or x86_64 in their PKGBUILD's architecture list. From the PKGBUILD man page:
arch (array)
Defines on which architectures the given package is available (e.g., arch=('i686' 'x86_64')). Packages that contain no architecture specific files should use arch=('any').
If you have a package whose source is portable C code, what should the PKGBUILD's architecture list be? From the man page description, I'd think 'any'. I can also imagine only including the architectures I've built and tested on, but then when would it make sense to use 'any' (since presumably even script based source should be tested on each architecture as well)?
Offline
Would the binary built on i686 work on x86_64? If not, use i686 and x86_64, not 'any'.
Offline
'any' is not the same as 'i686' and 'x86_64'. 'any' is only for packages that can be built once and installed on either architecture. This would be data-file only packages, and scripting languages (python, java).
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Ah, I see. So the man page is referring to the output of the build containing architecture specific files, not the input. I thought it meant something like having x86_64 specific assembly code as part of your input.
Offline
Yes, the output is the package. The input is just a PKGBUILD. So if the package will contain architecture specific files ... and any package with compiled binaries will be architecture-specific.
As to whether you should list both architectures when you haven't tested it on both - I'd generally say go for it. If you know there is anything that wouldn't build on another architecture then don't, but it if is reasonably portable code then list both.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
As to whether you should list both architectures when you haven't tested it on both - I'd generally say go for it. If you know there is anything that wouldn't build on another architecture then don't, but it if is reasonably portable code then list both.
I disagree, many software authors assume that the way ubuntu/debian and fedora/redhat setup things will work on everything.
Arch does several things different, which often means i686 and x86_64 need specific changes to work.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
I build for i686 before listing it, but don't test them beyond that.
Offline