@@ -41,3 +41,11 @@ There are two cross-compile types supported. [https://github.com/postmarketOS/pm
* <code>cache_distfiles</code>: Whenever you build a package, <code>abuild</code> (which pmbootstrap wraps) will download the source files to the <code>distfiles</code> cache (and skip these downloads, when they already exist). The exact file name can be controlled inside the APKBUILD ([https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#source more info]).
* <code>cache_git</code>: <code>pmbootstrap</code> can download git repositories. This gets used in <code>pmbootstrap aportgen</code>, which copies a package (aka. aport) from Alpine Linux and customizes it (for example: <code>gcc-armhf</code>), so we inherit all patches and changes automatically, without much maintenance work. The git repos get stored inside this folder.
* <code>cache_http</code>: This stores files, that get downloaded with [https://github.com/postmarketOS/pmbootstrap/blob/master/pmb/helpers/http.py <code>pmb.helpers.http.download()</code>], so they don't need to be downloaded again every time. Currently, this gets used for the initial download of Alpine Linux' main repositories <code>APKINDEX.tar.gz</code> and [https://pkgs.alpinelinux.org/package/edge/main/armhf/apk-tools-static apk-tools-static] (which is a static build of the <code>apk</code> package manager, used to set up the chroot).
=== Why noarch packages are built for each architecture ===
For a <code>noarch</code> package, we could in theory compile it once and then create symlinks to all arches pointing to the package where we have created it. And previous versions of pmbootstrap used to do that. But that makes dependency parsing hard.
For example: device packages are always <code>noarch</code>, so in theory you could compile the device package for your <code>armhf</code> device in <code>x86_64</code>, and then symlink it to the <code>armhf</code> package folder. But it would still depend on the kernel, which is <code>armhf</code> only for that device (assuming it is not mainlined, like most devices are right now). So it would not make sense to install it in <code>x86_64</code> anyway, and if you would want to build it, you could only really do it in <code>armhf</code> anyway, because that's where the kernel is available.
So to simplify it, it is handled like in Alpine now; noarch packages just get built for each arch independently.