Skip to content
This repository has been archived by the owner. It is now read-only.

add architecture specific dependency fields support #465

Closed
rmarquis opened this Issue Apr 4, 2016 · 7 comments

Comments

Projects
None yet
3 participants
@rmarquis
Copy link
Owner

commented Apr 4, 2016

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 AladW/aurutils#80.

@rmarquis rmarquis added the todo label Apr 4, 2016

@rmarquis rmarquis added this to the 4.6.x - new features milestone Apr 4, 2016

@Lucki

This comment has been minimized.

Copy link

commented Apr 24, 2016

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

This comment has been minimized.

Copy link
Owner Author

commented Apr 24, 2016

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

This comment has been minimized.

Copy link
Owner Author

commented Apr 25, 2016

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 rmarquis added the upstream label Aug 5, 2016

@rmarquis rmarquis modified the milestones: 4.6.x - maintenance, 5.0.x - later, 4.7.x - new features Oct 1, 2016

@rmarquis

This comment has been minimized.

Copy link
Owner Author

commented Jan 26, 2017

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

@rmarquis rmarquis added wontfix and removed todo labels Jan 26, 2017

@ArchangeGabriel

This comment has been minimized.

Copy link

commented Jan 26, 2017

@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

This comment has been minimized.

Copy link
Owner Author

commented Jan 26, 2017

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

@rmarquis

This comment has been minimized.

Copy link
Owner Author

commented Jul 27, 2017

This is superseded by #720, closing now.

@rmarquis rmarquis closed this Jul 27, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.