New comment by ericonr on void-packages repository

https://github.com/void-linux/void-packages/issues/27337#issuecomment-749295909

Comment:
> We will need tooling for managing these multilib prefixes. Using just xbps as it is is fairly clunky, because by default these prefixes don't have repos set up in them and so on. Especially initial setup is relatively involved.

This initial setup will be rather clunky, since it's not really possible to derive the repo path from whatever is configured in `/etc/xbps.d`; aarch64 has a completely different path from what arm uses, for example.

Just as a note for something that may not be immediately obvious, the reason we need the `/usr/lib32` symlink *as well as* the dynamic linker configuration, is that the latter affects how programs are loaded (where the linker looks for the libraries your program is linked against), while the former is a fix that will allow libraries like mesa and pulse to simply work, since they will search for things to dlopen in `/usr/lib32`.

A few concerns that came to mind now were:

- the case where a library looks for binary helpers (like PAM does, but you shouldn't have a copy of PAM in the alternate root, so it isn't a good example) in `/usr/libexec` will be kind of broken, unless one has the "native" counterparts installed and fully compatible.
- our `wine` package, specifically the `/usr/bin/wine` launcher, will need to be thoroughly fixed, but I'm not entirely sure how.
- and 

> There might be packages that require wordsize-specific data files in /usr/share. These need to be found, and such files need to go to /usr/lib(32|64). This is the right thing to do either way, since they're no different from binary files, /usr/share should only contain architecture-independent data.

At least one package that I know of is aspell.