On Sat, 26 Feb 2011 at 14:21:13 +0100, Sean Finney wrote:
> The Debian autobuilders only make use of the first alternative
> in a set of alternatives, in order to guarantee consistent,
> reproducible builds. This does not include architecture
> restrictions, because architecture reduction takes place before
> alternative removal. Alternatives are therefore allowed, and
> hence useful for backports and other distributions, but are not
> used by default.
> ---
> policy.sgml | 13 +++++++++++++
> 1 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/policy.sgml b/policy.sgml
> index 642f672..33a3a8a 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -4446,6 +4446,19 @@ Checksums-Sha256:
> by vertical bar (pipe) symbols <tt>|</tt>. In such a case,
> if any one of the alternative packages is installed, that
> part of the dependency is considered to be satisfied.
> + <footnote>
> + While <tt>Build-Depends</tt> and <tt>Build-Depends-Indep</tt>
> + 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.
> + </footnote>
> </p>
6½ years later, ideally this would mention Build-Depends-Arch too.
Other than that, seconded. I'm not sure whether this is necessarily how
the autobuilders *should* work, but there's value in documenting how
the autobuilders *do* work.
Regards,
smcv
