When a ?Package is built is usually contains architecture-dependent parts. These must be built for each architecture (arch) due to differences in the machine code used on the architecture. The architecture is dependent on things like the processor and the kernel used.
If a package contains arch-dependent parts the it is usually build with
debian/control. This means that it will be
built separately for wach architecture in Debian by the Buildds.
It is possible to specify a list of architectures there instead,
but this should only be done if the package has no place on the
other architectures. Not building on them is not a reason for doing
this as it is expected that packages should build on all architectures,
even if they are not able to yet. This should be done when the package
is designed for a specific architecture, for instance
which allows you to control the screen on the front
of some Sun servers, which only come in two architectures (i386 and SPARC).
If you upload a package with
Architecture: any, and it does not build on
a certain architecture then there will be a non-RC bug
filed against the package, possibly with one of the ?porters for that
architecture providing a patch to solve the problem. In any subsequent uploads
if the package fails to build (?FTBFS) on any architecture where it has
built previously then it will receive a ReleaseCritical bug report, and
will be expected to fix the problem. The rationale for this is that if it built
once on an architecture then it should build there again.
Some packages do not contain any architecture-dependent parts (it is arch-independent), for instance -doc packages or perl modules. These should have