[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#614807: debian-policy: Please document autobuilder-imposed build-dependency alternative restrictions



Hi all,


On Wed, 2011-02-23 at 18:22 +0000, Roger Leigh wrote:

> Feel free to phrase it better, or even remove that part, if it's
> unclear or not too helpful.

How about the attached?  It also condenses the text and makes it a
footnote just a bit further up, as it seemed a bit more appropriate
there and since it was not describing any particular rules but more
explanatory in nature.


	Sean
From 5a9f66da4f9e0ca92ed8cb4ff20225896963bf04 Mon Sep 17 00:00:00 2001
From: Sean Finney <seanius@debian.org>
Date: Wed, 23 Feb 2011 15:14:56 +0000
Subject: [PATCH] Document restrictions on alternative build dependencies

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>
 
 	<p>
-- 
1.7.2.3

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: