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