Bug#530687: debian-policy: Please provide policy for architecture wildcards
Hi!
On Tue, 2009-05-26 at 18:50:42 -0400, Andres Mejia wrote:
> 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>
Well ‘any’ is as much of a wildcard as are the more fine grained ones,
so probably we might want to describe them as being the same thing.
> @@ -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>
That seems a bit confusing regarding how this actually works, and with
the meaning of wildcard. The wildcards are not expanded then compared,
they are simply matched.
So just to clarify, but not as a proposal for addition into policy,
internally Dpkg::Arch normalizes the GNU triplets and the Debian
arches into Debian arch triplets (which are kind of inverted GNU
triplets). So when matching two Debian arch triplets, whenever an
‘any’ is found it matches with anything on the other side, like in:
gnu-linux-i386 == gnu-linux-any
gnu-kfreebsd-amd64 == any-any-amd64
And for example ‘any’ is normalized to ‘any-any-any’.
> @@ -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,
“on architectures using the Linux kernel and any cpu”?
> + <tt>bar</tt> on any kernel on the i386 architecture, and <tt>baz</tt>
“on architectures using any kernel and an i386 cpu”?
> + on any architecture for any kernel that is not Linux.
“on architectures using any kernel not being Linux and any cpu”?
> + </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
<os>-any and any-<cpu>.
> + 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>
As said before this is not correct, they are matched. Also using
architecture instead of cpu is going to be confusing.
> + <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>
This is also not correct, given that wildcards are never expanded, and
are actually propagated from debian/control to .dsc files. So they will
be always up to date in relation to the supported architectures in
dpkg-dev.
> <sect>
> <heading>Daemons</heading>
Thanks Andres for the initial proposal, I should have done this long
time ago. I might try to propose a different wording later, though.
regards,
guillem
Reply to: