Most popular Linux packages require their build system to be self-contained: packages are built on the same distribution and architecture as the one the package is supposed to be run on.
For example, dpkg package for Debian x86 is difficult to build on non-Debian system or on architecture incompatible to x86; rpm package for Fedora ARM is difficult to build on something other than Fedora or Fedora on ARM-incompatible architecture.
This is because scripts for building packages (.spec
file for rpm, rules file for dpkg) are written without any
provisions for cross-compilation (either cross-distro, or
cross-architecture one) and without clear separation between binaries
built for target system and binaries built to be run during build
process (like tests, for example).
As a result, in order to build a package for some distro and architecture, you need either a machine running this distro on this architecture, or some kind of virtualisation. However, these approaches have significant drawbacks.
Using a separate machine for each target distro and architecture is not feasible if you want to build your packages for several distros and several architectures: number of all combinations grow too quickly. Also, it can be too slow, especially for mobile devices: modern ARM-based computers are much less powerful than 64-bit x86-based workstations most developers use.
For the same architecture, but other distro, you need the target distro to be somehow isolated from the host system.
The simplest way is to use something like chroot with minimal set of packages from target distro installed. This requires root access to setup build environment and perform maintenance tasks (like upgrading target distro or installing new packages). Also, it can interfere with security extensions running on the host system (like SELinux or AppArmor).
Another solution is to use containers, like lxc or
Docker. This is essentially the same as chroot with stronger isolation,
and it has the same drawbacks as chroot solution.
Of course, you can use fully isolated virtual machine
(kvm, xen etc.), but this solution is even
more heavyweight and requires to install fully functional distribution,
with system bootstrap procedure and services required for remote access
to this system.
For other architecture, you need hardware emulation. This can be
setup without root access (using qemu, for example), but it
can be very slow: running fully emulated compiler for target
architecture is much less optimal than cross-compiler built to run on
host system natively.
ldbox provides another solution for building and
packaging software for linux distributions and architectures other the
host one that