New comment by Hoshpak on void-packages repository https://github.com/void-linux/void-packages/pull/540#issuecomment-417855681 Comment: So my computer just finished compiling all the dependencies, I will begin from the start so that everyone gets the full picture: Void never had true multiarch support the way Debian or other distributions implemented it. The only thing that comes somewhat close to it is the building of the `-32bit` packages which is more of a hack. It uses the i686 binaries built by the i686 builder and repackages them as `x86_64` binary packages with the `-32bit' suffix. So building the wine package the way proposed in this PR would require the necessary builds to have run on the i686 builder first and the multilib repository to be enabled during the build. Since both is the case in the current configuration, that would work if the template hits the builders. However `void-packages` is built on the premise that it is possible to bootstrap everything from sources without requiring any preexisting binary packages. So I should be able to always just clone this repository, not use any of the mirrors and build a whole system from the sources. That's also the reason why packages that require themselves to bootstrap something have two versions of them in the repository, one being binaries provided by upstream which can be used to bootstrap and build the package from source, the other one being the source of the packages which can then be built. Now if I try to compile wine with this template without using the existing repositories, it will fail because `xbps-src` can't find any of the `-32bit` packages. There is no template for them and `xbps-src` can't detect that it should build the packages without suffix for i686 first to have them available. That's what was referred to in https://github.com/voidlinux/void-packages/pull/11534 as > bootstrap issues The proper solution for this would be to implement true multiarch support in Void which would be a huge amount of work and extend `xbps-src` to make it possible to depend on packages for a different architecture and then automatically (cross)compiling the necessary packages for the specified architecture.