debian mentors/ glossary/ Architecture
.........................

Architecture

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 

  Architecture: any

in 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 cobalt-panel-utils, 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

  Architecture: all

in debian/control, which means they can be installed on every arcitecture. These packages are not built on the Buildds, as the BinaryPackage that is uploaded is sufficient for everyone.

Links