Bug#400322: Limiting non-build-time relationships to a set of architectures?

[Russ Allbery <rra@debian.org>]

Quoting a lot here for context on this old Policy bug.

Guillem Jover <guillem@debian.org> writes:
> On Tue, 2010-02-09 at 20:25:11 +0100, Cyril Brulebois wrote:
>> Frans Pop <elendil@planet.nl> (09/02/2010):
>>> On Tuesday 09 February 2010, Cyril Brulebois wrote:
>>>> Frans Pop <elendil@planet.nl> (09/02/2010):

>>>>> This format is not (yet) allowed by policy: rootskel-gtk
>>>>> (>=0.05) [!s390] (except for build dependencies)

>>>> AFAICT, it just works, and not only for Build-Depends. It can't be
>>>> used for an arch: all package, though, since it gets substituted at
>>>> build time, so it probably won't do what you would want.

>>> I know that it is going to be allowed in the future and because of
>>> that I don't doubt that it (mostly?) works.  But AFAIK *currently*
>>> it's not allowed by policy [1], except for build deps. And thus it
>>> should not yet be used in uploads.

> Actually checking now, there does not seem to have been any wording
> proposed yet on #400322, I might try to come up with one.

>> Oops, indeed. Looks like I forgot about that particular point, thanks
>> for pointing this out. It looks like I've been taking it granted for
>> quite some time.

> Hmm, I also seem to have forgotten about this (I'll call that fair
> bias :). I was curious anyway about how long this support has been
> around as I thought it had been long, so did some digging the other
> day:

>  * Introduced in dpkg 1.10.11 (Tue, 16 Sep 2003 12:52:11 -0500)
>    Bug: #170575

>  * Regression in dpkg 1.10.14 (Fri, 19 Sep 2003 12:29:34 -0500)

>  * Fixed again in dpkg 1.13.17 (Mon, 20 Mar 2006 03:33:03 +0200)
>    Bugs: #252657, #324741, #347819

> Also I don't think much tools except for dpkg-dev scripts actually parse
> the dependency fields in the binary package stanzas in
> debian/control. So this should supposedly not break stuff (but then I've
> not checked, etc).

If this already works, we should document it, since it can be quite
useful.  Here's an attempt at wording.  Please check this and make sure
that I'm correctly documenting what works.

Do architecture restrictions work with Provides?  This documentation says
that they do, but I can easily correct that if it's wrong.

diff --git a/policy.sgml b/policy.sgml
index bad28af..316f753 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -4373,21 +4373,24 @@ Depends: libc6 (>= 2.2.1), exim | mail-transport-agent
 	</p>
 
         <p>
-          All fields that specify build-time relationships
+	  Relationships may be restricted to a certain set of
+	  architectures.  This is indicated in brackets after each
+	  individual package name and the optional version specification.
+	  The brackets enclose a list of Debian architecture names
+	  separated by whitespace.  Exclamation marks may be prepended to
+	  each of the names.  (It is not permitted for some names to be
+	  prepended with exclamation marks while others aren't.)
+	</p>
+
+	<p>
+	  For build relationship fields
 	  (<tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>,
-	  <tt>Build-Conflicts</tt> and <tt>Build-Conflicts-Indep</tt>)
-	  may be restricted to a certain set of architectures.  This
-	  is indicated in brackets after each individual package name and
-	  the optional version specification.  The brackets enclose a
-	  list of Debian architecture names separated by whitespace.
-	  Exclamation marks may be prepended to each of the names.
-	  (It is not permitted for some names to be prepended with
-	  exclamation marks while others aren't.) If the current Debian
-	  host architecture is not in this list and there are no
-	  exclamation marks in the list, or it is in the list with a
-	  prepended exclamation mark, the package name and the
-	  associated version specification are ignored completely for
-	  the purposes of defining the relationships.
+	  <tt>Build-Conflicts</tt> and <tt>Build-Conflicts-Indep</tt>), if
+	  the current Debian host architecture is not in this list and
+	  there are no exclamation marks in the list, or it is in the list
+	  with a prepended exclamation mark, the package name and the
+	  associated version specification are ignored completely for the
+	  purposes of defining the relationships.
 	</p>
 
 	<p>
@@ -4404,6 +4407,29 @@ Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
 	</p>
 
 	<p>
+	  For binary relationship fields, the architecture restriction
+	  syntax is only supported in the source package control
+	  file <file>debian/control</file>.  When the corresponding binary
+	  package control file is generated, the relationship will either
+	  be omitted or included without the architecture restriction
+	  based on the architecture of the binary package.  This means
+	  that architecture restrictions must not be used in binary
+	  relationship fields for architecture-independent packages
+	  (<tt>Architecture: all</tt>).
+	</p>
+
+	<p>
+	  For example:
+	  <example compact="compact">
+Depends: foo [i386], bar [amd64]
+	  </example>
+	  becomes <tt>Depends: foo</tt> when the package is built on
+	  the <tt>i386</tt> architecture, <tt>Depends: bar</tt> when the
+	  package is built on the <tt>amd64</tt> architecture, and omitted
+	  entirely in binary packages built on all other architectures.
+	</p>
+
+	<p>
 	  If the architecture-restricted dependency is part of a set of
 	  alternatives using <tt>|</tt>, that alternative is ignored
 	  completely on architectures that do not match the restriction.
@@ -4417,11 +4443,11 @@ Build-Depends: foo [!i386] | bar [!amd64]
 	</p>
 
         <p>
-	  All fields that specify build-time relationships may also be
-	  restricted to a certain set of architectures using architecture
-	  wildcards.  The syntax for declaring such restrictions is the
-	  same as declaring restrictions using a certain set of
-	  architectures without architecture wildcards.  For example:
+	  Relationships may also be restricted to a certain set of
+	  architectures using architecture wildcards.  The syntax for
+	  declaring such restrictions is the same as declaring
+	  restrictions using a certain set of architectures without
+	  architecture wildcards.  For example:
           <example compact="compact">
 Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
           </example>

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>