What is xcontrol?

debian/xcontrol is an extended version of debian/control, allowing the use of new fields and (slight) redefinition of others; examples for possible new fields include cross-compilation hints, information about optional targets in the rules file and rules for generating new Package stanzas.

The xcontrol file can be converted to a policy-compliant control file using the xcontrol(1) utility, found in the debian-xcontrol package.

What works so far?


(since 0.0.1) The Build-Depends-Tools field lists build dependencies that you would want to install on the host machine when cross compiling; regular Build-Depends are reinterpreted so that they are installed for the target machine. Build-Depends-Indep will still be installed on the host system (there is no real point in cross-compiling arch:all packages).

(starting with 0.0.2) the xdpkg-checkbuilddeps tool can be used to check whether the build dependencies for a native or cross build are installed.

This field is merged with the Build-Depends field, thereby losing the distinction between host and target build dependencies, for the policy-compliant control file.

Optional packages

(since 0.0.4) A package declared Optional is not built by default, but can be explicitly requested by invoking the "build-packagename" and "binary-packagename" targets. This is mainly useful for bootstrapping (see below), but could be extended to other uses

Bootstrap packages

(since 0.0.4) A package declared Bootstrap should not be uploaded (and is implicitly Optional); the source package's Build-Depends and build-essential are not required for its build (so if you need anything, declare it in the per-package build dependencies).

These packages can be used to break dependency loops in a bootstrap process, building them should be avoided if possible.

Per-Package build dependencies

(since 0.0.4) Additional (or in the case of bootstrap packages, replacement) build dependencies can be declared in the binary package stanza.

What is being implemented?

What is being thought about?

Backporting hints

When backporting, it is often acceptable to substitute or omit build dependencies. Having a way to specify these directly in the source package in unstable would allow an autobuilder to take the unmodified package without further human interaction. The list of backport targets is mostly orthogonal to the available Variants, although some overlap in functionality exists.


Similar to Gentoo's USE flags, it should be possible to build different configurations of the same package from one single source package. Likely variants of a package would be "Debian", "Ubuntu", "emdebian", i.e. contrary to USE flags, this would be a high-level approach.

Package templates

Preferences for derived distributions

Derived distributions, such as Ubuntu, face a certain dilemma when taking over packages from Debian. On the one hand, the Debian maintainers should be credited for their work, on the other hand, since they were not the last person to touch the package, they should not be held directly responsible for them.

Ubuntu uses the X-Original-Maintainer field for this: the Debian maintainer information is copied there, and the person or group responsible for the Ubuntu package is set as the Maintainer.

This is not an ideal solution, since individual preferences on attribution vary; it has been felt that there should be a way to specify when to move the Maintainer information to X-Original-Maintainer, and when to remove that information altogether.

Also, in the case that the Debian and Ubuntu maintainers for a package are the same people, it may still be desired to use different Maintainer fields for each distribution, ideally without changing the source code. It has therefore been suggested to allow multiple tagged maintainer fields, where the appropriate one is selected during package build. This could possibly be integrated with the Variants handling.

What has been suggested?

(this is where you add your ideas.)

Depends-Debtags, Recommends-Debtags, Suggests-Debtags

The Depends-Debtags, Recommends-Debtags, Suggests-Debtags fields expands to the result of a debtags lookup of the value used as tag expression.

As an example, the meta package debian-arcade currently contains the following:

Package: junior-arcade
Architecture: all
Depends: bugsquish, bumprace, circuslinux, cuyo, heroes, holotz-castle,
    koules, lbreakout2, madbomber, supertux, tuxmath, xsoldier
Description: Debian Jr. arcade games

An xcontrol file could achieve the above setup like this:

Package: junior-arcade
Architecture: all
Depends-Debtags: junior::arcade && !role::shared-lib && !role::app-data
Description: Debian Jr. arcade games

...or if the debtags maintainers should decide include a couple of more generic facets instead of the cdd-specific "junior", it could look like this:

Depends-Debtags: games::arcade && !nudity::* && !violence::* && complexity::simple && !role::shared-lib && !role::app-data

To test the outcome of a debtags expression, the following command can be used:

debtags search --names <tag expression>

An optional local debtags database placed as debian/debtags (or debian/<package>.debtags) is used instead of the central debtags database. This can be tested with debtags --vocabolary=debian/debtags.

If both ordinary dependencies and debtags-extended ones exist, then the expansion of the debtags field is added to the end of the ordinary one.

Depends-Relaxed, Recommends-Relaxed(, Depends-Debtags-Relaxed, Recommends-Debtags-Relaxed)

Each package in these fields is checked for availability on the actual architecture. If it exists it is merged with same non-relaxed field. If the package does not exist on this architecture, it is instead merged with Suggests.

This is to maintain package dependencies for metapackages across all architectures, and still respect the policy requirement of fulfilling both depends and recommends.