Architecture¶

If a program needs to specify an architecture specification string in some place, it should select one of the strings provided by dpkg-architecture -L. The strings are in the format os-arch, though the OS part is sometimes elided, as when the OS is Linux. A package may specify an architecture wildcard. Architecture wildcards are in the format any (which matches every architecture), os-any, or any-cpu. For more details, see Debian policy <http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-arch-spec> Mandatory. Type string.

Multi-Arch¶

This field is used to indicate how this package should behave on a multi-arch installations. This field should not be present in packages with the Architecture: all field. Optional. Type enum. choice: 'same', 'foreign', 'allowed'.

Here are some explanations on the possible values:

'allowed'

allows reverse-dependencies to indicate in their Depends field that they need a package from a foreign architecture, but has no effect otherwise.

'foreign'

the package is not co-installable with itself, but should be allowed to satisfy the dependency of a package of a different arch from itself.

'same'

the package is co-installable with itself, but it must not be used to satisfy the dependency of any package of a different architecture from itself.

Section¶

Optional. Type uniline.

Note: Section is computed with '$source' and with:

•

$source => "- - source Section"

Priority¶

Optional. Type enum. choice: 'required', 'important', 'standard', 'optional', 'extra'.

Note: Priority is computed with '$source' and with:

•

$source => "- - source Priority"

Essential - The package is essential as defined by Debian Policy¶

The package is an essential package as defined by Debian Policy. The following rules apply to the package:

• Essential packages are considered essential for the system to work. The packaging system (APT and dpkg) will warn and refuse to uninstall them without some very insistent force options.
• Other packages are not required to declare explicit dependencies on essential packages as a side-effect of the above except as needed to ensure that the given essential package is upgraded to a given minimum version.
• Once installed, essential packages must function at all times no matter where dpkg is in its installation or upgrade process. During bootstrapping or installation, this requirement is relaxed.

Note that if you are looking for a way to prevent accidental uninstallation, please consider using "Protected: yes" instead. Optional. Type boolean.

XB-Important - Obsolete and incomplete variant of the Protected field¶

This is the prototype field that led to `Protected`, which should be used instead.

It makes `apt` (but not `dpkg`) require extra confirmation before removing the package. Deprecated Optional. Type boolean.

upstream_default value :

no

Protected - Mark as Protected (uninstall protection)¶

Declare this package as a system critical package. When the field is set to "yes", both "apt" and "dpkg" will assume that removing the package may break the system. As a consequence, they will require extra confirmation (or "force" options) before removing the package. This field basically provides "uninstall" protection similar to that of "Essential" packages without the other benefits and requirements that come with "Essential" packages. In a Debian context, this field is generally applicable to packages like bootloaders, kernels, and other packages that might be necessary for booting the system. Optional. Type boolean.

upstream_default value :

no

Here are some explanations on the possible values:

'no'

The package is a regular package. This is the default and recommended.

'yes'

The package is protected and attempts to uninstall it will cause strong warnings to the user that they might be breaking the system.

Note: Protected is migrated with '$xbi' and with:

•

$xbi => "- XB-Important"

Depends - declares an absolute dependency.¶

The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality. See also debian policy <https://www.debian.org/doc/debian-policy/ch-relationships.html> Optional. Type list of uniline.

Recommends - declares a strong, but not absolute, dependency.¶

This field should list packages that would be found together with this one in all but unusual installations. See also debian policy <https://www.debian.org/doc/debian-policy/ch-relationships.html> Optional. Type list of uniline.

Suggests - declare that one package may be more useful with one or more others.¶

Using this field tells the packaging system and the user that the listed packages are related to this one and can perhaps enhance its usefulness, but that installing this one without them is perfectly reasonable. See also debian policy <https://www.debian.org/doc/debian-policy/ch-relationships.html> Optional. Type list of uniline.

Enhances - declare that a package can enhance the functionality of another package¶

This field is similar to Suggests but works in the opposite direction. It is used to declare that a package can enhance the functionality of another package. See also debian policy <https://www.debian.org/doc/debian-policy/ch-relationships.html> Optional. Type list of uniline.

Pre-Depends¶

This field is like Depends, except that it also forces dpkg to complete installation of the packages named before even starting the installation of the package which declares the pre-dependency. See also debian policy <https://www.debian.org/doc/debian-policy/ch-relationships.html> Optional. Type list of uniline.

Breaks¶

When one binary package declares that it breaks another, dpkg will refuse to allow the package which declares Breaks to be unpacked unless the broken package is deconfigured first, and it will refuse to allow the broken package to be reconfigured. See also debian policy <https://www.debian.org/doc/debian-policy/ch-relationships.html> Optional. Type list of uniline.

Conflicts¶

When one binary package declares a conflict with another using a Conflicts field, dpkg will refuse to allow them to be unpacked on the system at the same time. This is a stronger restriction than Breaks, which prevents the broken package from being configured while the breaking package is in the "Unpacked" state but allows both packages to be unpacked at the same time. See also debian policy <https://www.debian.org/doc/debian-policy/ch-relationships.html> Optional. Type list of uniline.

Provides¶

declare the functionality brought by this package. Be sure to read the chapter about virtual package in debian policy <https://www.debian.org/doc/debian-policy/ch-relationships.html> before using this parameter. Optional. Type list of uniline.

Replaces¶

declare that this package should overwrite files in certain other packages, or completely replace other packages. Be sure to read the section 7.6 of debian policy <https://www.debian.org/doc/debian-policy/ch-relationships.html> before using this parameter. Optional. Type list of uniline.

Built-Using - Additional source packages used to build the binary¶

Some binary packages incorporate parts of other packages when built but do not have to depend on those packages. Examples include linking with static libraries or incorporating source code from another package during the build. In this case, the source packages of those other packages are a required part of the complete source (the binary package is not reproducible without them).

A Built-Using field must list the corresponding source package for any such binary package incorporated during the build, including an "exactly equal" ("=") version relation on the version that was used to build that binary package.

A package using the source code from the gcc-4.6-source binary package built from the gcc-4.6 source package would have this field in its control file:

     Built-Using: gcc-4.6 (= 4.6.0-11)

A package including binaries from grub2 and loadlin would have this field in its control file:

     Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1) I< Optional. Type list of uniline.  >

Package-Type - The type of the package, if not a regular Debian one¶

If this field is present, the package is not a regular Debian package, but either a udeb generated for the Debian installer or a tdeb containing translated debconf strings. Optional. Type enum. choice: 'tdeb', 'udeb'.

Note: Package-Type is migrated with '$xc' and with:

•

$xc => "- XC-Package-Type"

XC-Package-Type - The type of the package, if not a regular Debian one¶

If this field is present, the package is not a regular Debian package, but either a udeb generated for the Debian installer or a tdeb containing translated debconf strings. Deprecated Optional. Type enum. choice: 'tdeb', 'udeb'.

Synopsis¶

Mandatory. Type uniline.

Description¶

Mandatory. Type string.

Homepage¶

Optional. Type uniline.

XB-Python-Version¶

Deprecated Optional. Type uniline.

XB-Ruby-Versions¶

indicate the versions of the interpreter supported by the library. Deprecated Optional. Type uniline.

X-DhRuby-Root - For multi-binary layout with the dh_ruby tool¶

Used by "dh_ruby" to request "multi-binary" layout and where the root for the given package is.

Please refer to dh_ruby <https://manpages.debian.org/dh_ruby> documentation for more details. Optional. Type uniline.

Build-Profiles¶

Build-Profiles specifies the condition for which that binary package does or does not build.

This is expressed as a list of lists of (optionally negated) profile names, forming a conjunctive normal form expression in the same syntax as in the Build-Depends field.

For instance:

    Build-Profiles: <!cross> <!nocheck>

See <https://wiki.debian.org/BuildProfileSpec#The_Build-Profiles_field> for more details. Optional. Type uniline.

XB-Installer-Menu-Item - Package's order in the debian-installer menu (udeb-only)¶

This field is only relevant for "udeb" packages (debian-installer).

The field is used to declare where in the installer menu this package's menu item should be placed (assuming it has any menu item). For packages targeting the Debian archive, any new package should have its menu item number aligned with the debian-installer team before upload.

A menu item is 4-5 digits (In the range "1000 <= X <= 99999"). In rare cases, the menu item can be architecture dependent. For architecture dependent menu item values, use a custom substvar.

See <https://d-i.debian.org/doc/internals/apa.html> for the full list of menu item ranges and for how to request a number. Optional. Type uniline.

X-DH-Build-For-Type - For cross-compiling cross-compilers¶

Special-purpose only. This field is a special purpose field and is rarely needed. Leave it out unless you know you need it or someone told you to use it.

This field is used when building a cross-compiling C-compiler (or similar cases). Some packages need to be built for the target (DEB_TARGET_ARCH) rather than the host (DEB_HOST_ARCH) architecture. Optional. Type enum. choice: 'host', 'target'.

upstream_default value :

host

Here are some explanations on the possible values:

'host'

The package should be compiled for "DEB_HOST_ARCH", which is the default behavior.

'target'

The package should be compiled for "DEB_TARGET_ARCH".

For steps that look at the values from "dpkg-architecture" and that are specific to this package, the "DEB_TARGET_" variants are used instead of the "DEB_HOST_" variants. In "debhelper", this usually affects "dh_makeshlibs" and "dh_shlibdeps". In "debputy", it affects the parts of the manifest that are run in a package specific context, such as the parts beneath the "packages" root-level keyword.

This value is exceedingly rare to the point where if you do not know you need it, then you are not looking for this value (or the field in general).

X-Time64-Compat - (Special purpose) Compat name for time64_t transition¶

Special purpose field related to the 64-bit time transition.

It is used to inform packaging helpers what the original (non-transitioned) package name was when the auto-detection is inadequate. The non-transitioned package name is then conditionally provided in the "${{t64:Provides}}" substitution variable.

The field only works for architecture dependent packages. Optional. Type uniline.