add architecture specific dependency fields support

[rmarquis]

Currently, the RPC interface doesn't support architecture specific fields. It merges them in the generic arrays instead. See FS#48796.

Partial support for arch specific dependencies has been implemented with a temporary workaround in 6e3cb3b. This will however work only if the 32 bits (make)dependencies use the naming prefix lib32- on on the x86_64 arch, and the regular name on the i686 arch. Most user cases should be covered by this hack, but probably not all (I'm still looking for a test case where this hack actually fails).

It is possible to implement another temporary hack by reading and parsing the .SRCINFO files to retrieve the correct information. This indeed bypasses the RPC interface, and is implemented by bauerbill and pkgbuilder. This would however require to substantially change the current design as PKGBUILD cloning is done after dependency resolution, and this is something I'm not going to do. I will instead wait for the proper fix to be implemented in the RPC. Once this is done, correct arch specific support will be trivial to add and the existing hack can be removed.

See also wiki discussion and aurutils/aurutils#80.

[Lucki]

I'm still looking for a test case where this hack actually fails

I hope this is the same issue:
Before building openrct2-git on a 32-bit-machine, pacaur fails at resolving dependencies… with no results found for gcc-multilib which isn't available for 32-bit-systems.
The dependency is declared for 64-bit makedepends_x86_64=('gcc-multilib') so it should affect 32-bit.

[rmarquis]

Yes, this is the same issue and a situation where the simplistic hack above fails. Unfortunately, handling this package requires FS#48796 to be fixed first as explained above.

[rmarquis]

I've expanded the current hack to handle gcc-multilib as it's always needed with lib32 packages on 64 bit arch anyway (see 4d36c53).

[rmarquis]

Note: Arch is phasing out i686 support. No further work is therefore needed, and the current hack can be removed in November 2017.

[ArchangeGabriel]

@rmarquis You got it wrong I think. Official i686 support in the repo from current devs is what is going out.

i686 will probably stay, the ideal goal being to have it built in an automated manner by the end of the year. But what is sure, is that support for multiple architectures will stay in all the tools.

That being said, I’m not asking you to spend any of your time on this issue until at least the future of i686 is established. ;)

[rmarquis]

True, the official support is ending. We'll see if a viable community effort happens.

[rmarquis]

This is superseded by #720, closing now.