7.8. Additional source packages used to build the binary - Built-Using

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 part of the complete source (the binary package is not reproducible without them).

When the license of either the incorporated parts or the incorporating binary package requires that the full source code of the incorporating binary package be made available, the Built-Using field must list the corresponding source package for any affected binary package incorporated during the build, 6 including an “exactly equal” (“=”) version relation on the version that was used to build that version of the incorporating binary package. 7

This causes the Debian archive to retain the versions of the source packages that were actually incorporated. In particular, if the versions of the incorporated parts are updated but the incorporating binary package is not rebuilt, the older versions of the incorporated parts will remain in the archive in order to satisfy the license.

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)

This field should be used only when there are license or DFSG requirements to retain the referenced source packages. It should not be added solely as a way to locate packages that need to be rebuilt against newer versions of their build dependencies.

1

While Build-Depends, Build-Depends-Indep and Build-Depends-Arch permit the use of alternative dependencies, these are not normally used by the Debian autobuilders. To avoid inconsistency between repeated builds of a package, the autobuilders will default to selecting the first alternative, after reducing any architecture-specific restrictions for the build architecture in question. While this may limit the usefulness of alternatives in a single release, they can still be used to provide flexibility in building the same package across multiple distributions or releases, where a particular dependency is met by differently named packages.

2

The relations < and > were previously allowed, but they were confusingly defined to mean earlier/later or equal rather than strictly earlier/later. dpkg still supports them with a warning, but they are no longer allowed by Debian Policy.

3

This approach makes dependency resolution easier. If two packages A and B are being upgraded, the installed package A depends on exactly the installed package B, and the new package A depends on exactly the new package B (a common situation when upgrading shared libraries and their corresponding development packages), satisfying the dependencies at every stage of the upgrade would be impossible. This relaxed restriction means that both new packages can be unpacked together and then configured in their dependency order.

4

To see why Breaks is normally needed in addition to Replaces, consider the case of a file in the package foo being taken over by the package foo-data. Replaces will allow foo-data to be installed and take over that file. However, without Breaks, nothing requires foo to be upgraded to a newer version that knows it does not include that file and instead depends on foo-data. Nothing would prevent the new foo-data package from being installed and then removed, removing the file that it took over from foo. After that operation, the package manager would think the system was in a consistent state, but the foo package would be missing one of its files.

5

Replaces is a one way relationship. You have to install the replacing package after the replaced package.

6

Build-Depends in the source package is not adequate since it (rightfully) does not document the exact version used in the build.

7

The archive software might reject packages that refer to non-existent sources.