Bug#530687: debian-policy: Please provide policy for architecture wildcards
Package: debian-policy
Version: 3.8.1.0
Severity: wishlist
Tags: patch
Support for architecture wildcards has been added to dpkg-1.13.13, yet there's
no clear policy as to how architecture wildcards should be used for other tools
such as sbuild and pbuilder.
There has been recent discussions about making use of architecture wildcards [1]
and it's been suggested that some patch be provided to policy[1], so here is my
proposal, in the form of a patch.
diff --git a/policy.sgml b/policy.sgml
index 144cbfb..d0fb4d8 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -2711,6 +2711,8 @@ Package: libc6
<list>
<item>A unique single word identifying a Debian machine
architecture, see <ref id="arch-spec">.
+ <item>An architecture wildcard identifying a set of Debian
+ machine architectures, see <ref id="arch-wildcard-spec">.
<item><tt>all</tt>, which indicates an
architecture-independent package.
<item><tt>any</tt>, which indicates a package available
@@ -2723,7 +2725,8 @@ Package: libc6
In the main <file>debian/control</file> file in the source
package, or in the source package control file
<file>.dsc</file>, one may specify a list of architectures
- separated by spaces, or the special values <tt>any</tt> or
+ separated by spaces, a list of architecture wildcards separated by
+ spaces, or the special values <tt>any</tt> or
<tt>all</tt>.
</p>
@@ -2749,6 +2752,19 @@ Package: libc6
</p>
<p>
+ Specifying a list of architecture wildcards indicates that the
+ source will build an architecture-dependent package on the union of
+ the lists of architectures from the expansion of each specified
+ architecture wildcard, and will only work correctly on the
+ architectures in the union of the lists.<footnote>
+ As mentioned in the footnote for specifying a list of
+ architectures, this is a setting for a minority of cases where
+ the program is not portable. Generally, it should not be used
+ for new packages.
+ </footnote>
+ </p>
+
+ <p>
In a <file>.changes</file> file, the <tt>Architecture</tt>
field lists the architecture(s) of the package(s)
currently being uploaded. This will be a list; if the
@@ -4236,6 +4252,23 @@ Build-Depends: foo [!i386] | bar [!amd64]
source package section of the control file (which is the
first section).
</p>
+
+ <p>
+ All fields that specify build-time relationships
+ (<tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>,
+ <tt>Build-Conflicts</tt> and <tt>Build-Conflicts-Indep</tt>) 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>
+ is equivalent to <tt>foo</tt> on any architecture in the Linux kernel,
+ <tt>bar</tt> on any kernel on the i386 architecture, and <tt>baz</tt>
+ on any architecture for any kernel that is not Linux.
+ </p>
</sect>
<sect id="binarydeps">
@@ -7847,6 +7880,32 @@ done
</p>
</sect>
+ <sect id="arch-wildcard-spec">
+ <heading>Architecture Wildcards</heading>
+
+ <p>
+ A program may specify an architecture wildcard. Architecture
+ wildcards are in the format <tt><var>os</var></tt>-any and
+ any-<tt><var>arch</var></tt>. Specifying an architecture wildcard
+ would be equivalent to specifying a list of architecture
+ specification strings provided by <file>dpkg-architecture -L</file>
+ for a particular os or archictecture.
+ </p>
+
+ <p>
+ For example, specifying <tt>linux-any</tt> would be the same as
+ specifying <tt>armel lpia i386 ia64 alpha amd64 armeb arm hppa m32r
+ m68k mips mipsel powerpc ppc64 s390 s390x sh3 sh3eb sh4 sh4eb
+ sparc</tt>.
+ </p>
+
+ <p>
+ Specifying <tt>any-i386</tt> would be the same as specifying <tt>i386
+ kfreebsd-i386 knetbsd-i386 hurd-i386 darwin-i386 freebsd-i386
+ netbsd-i386 openbsd-i386 solaris-i386</tt>.
+ </p>
+ </sect>
+
<sect>
<heading>Daemons</heading>
The basis for this proposal is from the patch I supplied for sbuild. See bug
#501230.
Note: This patch applies to the latest debian-policy in git.
1. http://lists.debian.org/debian-devel/2009/05/msg00448.html
2. http://lists.debian.org/debian-devel/2009/02/msg00290.html
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.29-2-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
debian-policy depends on no packages.
debian-policy recommends no packages.
Versions of packages debian-policy suggests:
ii doc-base 0.9.2 utilities to manage online documen
-- no debconf information
diff --git a/policy.sgml b/policy.sgml
index 144cbfb..d0fb4d8 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -2711,6 +2711,8 @@ Package: libc6
<list>
<item>A unique single word identifying a Debian machine
architecture, see <ref id="arch-spec">.
+ <item>An architecture wildcard identifying a set of Debian
+ machine architectures, see <ref id="arch-wildcard-spec">.
<item><tt>all</tt>, which indicates an
architecture-independent package.
<item><tt>any</tt>, which indicates a package available
@@ -2723,7 +2725,8 @@ Package: libc6
In the main <file>debian/control</file> file in the source
package, or in the source package control file
<file>.dsc</file>, one may specify a list of architectures
- separated by spaces, or the special values <tt>any</tt> or
+ separated by spaces, a list of architecture wildcards separated by
+ spaces, or the special values <tt>any</tt> or
<tt>all</tt>.
</p>
@@ -2749,6 +2752,19 @@ Package: libc6
</p>
<p>
+ Specifying a list of architecture wildcards indicates that the
+ source will build an architecture-dependent package on the union of
+ the lists of architectures from the expansion of each specified
+ architecture wildcard, and will only work correctly on the
+ architectures in the union of the lists.<footnote>
+ As mentioned in the footnote for specifying a list of
+ architectures, this is a setting for a minority of cases where
+ the program is not portable. Generally, it should not be used
+ for new packages.
+ </footnote>
+ </p>
+
+ <p>
In a <file>.changes</file> file, the <tt>Architecture</tt>
field lists the architecture(s) of the package(s)
currently being uploaded. This will be a list; if the
@@ -4236,6 +4252,23 @@ Build-Depends: foo [!i386] | bar [!amd64]
source package section of the control file (which is the
first section).
</p>
+
+ <p>
+ All fields that specify build-time relationships
+ (<tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>,
+ <tt>Build-Conflicts</tt> and <tt>Build-Conflicts-Indep</tt>) 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>
+ is equivalent to <tt>foo</tt> on any architecture in the Linux kernel,
+ <tt>bar</tt> on any kernel on the i386 architecture, and <tt>baz</tt>
+ on any architecture for any kernel that is not Linux.
+ </p>
</sect>
<sect id="binarydeps">
@@ -7847,6 +7880,32 @@ done
</p>
</sect>
+ <sect id="arch-wildcard-spec">
+ <heading>Architecture Wildcards</heading>
+
+ <p>
+ A program may specify an architecture wildcard. Architecture
+ wildcards are in the format <tt><var>os</var></tt>-any and
+ any-<tt><var>arch</var></tt>. Specifying an architecture wildcard
+ would be equivalent to specifying a list of architecture
+ specification strings provided by <file>dpkg-architecture -L</file>
+ for a particular os or archictecture.
+ </p>
+
+ <p>
+ For example, specifying <tt>linux-any</tt> would be the same as
+ specifying <tt>armel lpia i386 ia64 alpha amd64 armeb arm hppa m32r
+ m68k mips mipsel powerpc ppc64 s390 s390x sh3 sh3eb sh4 sh4eb
+ sparc</tt>.
+ </p>
+
+ <p>
+ Specifying <tt>any-i386</tt> would be the same as specifying <tt>i386
+ kfreebsd-i386 knetbsd-i386 hurd-i386 darwin-i386 freebsd-i386
+ netbsd-i386 openbsd-i386 solaris-i386</tt>.
+ </p>
+ </sect>
+
<sect>
<heading>Daemons</heading>
Reply to: