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 itemA unique single word identifying a Debian machine architecture, see ref id=arch-spec. + itemAn architecture wildcard identifying a set of Debian + machine architectures, see ref id=arch-wildcard-spec. itemttall/tt, which indicates an architecture-independent package. itemttany/tt, which indicates a package available @@ -2723,7 +2725,8 @@ Package: libc6 In the main filedebian/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 ttany/tt or + separated by spaces, a list of architecture wildcards separated by + spaces, or the special values ttany/tt or ttall/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 + (ttBuild-Depends/tt, ttBuild-Depends-Indep/tt, + ttBuild-Conflicts/tt and ttBuild-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 ttfoo/tt on any architecture in the Linux kernel, “on architectures using the Linux kernel and any cpu”? + ttbar/tt on any kernel on the i386 architecture, and ttbaz/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 + headingArchitecture Wildcards/heading + + p + A program may specify an architecture wildcard. Architecture + wildcards are in the format ttvaros/var/tt-any and + any-ttvararch/var/tt. Specifying an architecture wildcard os-any and any-cpu. + would be equivalent to specifying a list of architecture + specification strings provided by filedpkg-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 +
Bug#530687: debian-policy: Please provide policy for architecture wildcards
On Tue, May 26, 2009 at 18:50:42 -0400, Andres Mejia wrote: @@ -2723,7 +2725,8 @@ Package: libc6 In the main filedebian/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 ttany/tt or + separated by spaces, a list of architecture wildcards separated by + spaces, or the special values ttany/tt or ttall/tt. /p This makes it sound like you can't mix architecture names and architecture wildcards. Is that on purpose? Cheers, Julien -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530687: debian-policy: Please provide policy for architecture wildcards
On Wednesday 27 May 2009 06:51:58 Julien Cristau wrote: On Tue, May 26, 2009 at 18:50:42 -0400, Andres Mejia wrote: @@ -2723,7 +2725,8 @@ Package: libc6 In the main filedebian/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 ttany/tt or + separated by spaces, a list of architecture wildcards separated by + spaces, or the special values ttany/tt or ttall/tt. /p This makes it sound like you can't mix architecture names and architecture wildcards. Is that on purpose? Cheers, Julien Current policy has this wording and I didn't want to change that, so yes, it's on purpose. My assumption is that however wrote this part of policy meant 'or' to be inclusive, not exclusive. Somebody already raised this issue about current policy. See [1]. 1. http://lists.debian.org/debian-policy/2009/05/msg00108.html -- Regards, Andres -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530687: debian-policy: Please provide policy for architecture wildcards
On Wed, May 27, 2009 at 07:30:57 -0400, Andres Mejia wrote: On Wednesday 27 May 2009 06:51:58 Julien Cristau wrote: This makes it sound like you can't mix architecture names and architecture wildcards. Is that on purpose? Current policy has this wording and I didn't want to change that, so yes, it's on purpose. Not quite. Current policy says arch list or 'any' or 'all' and that's fine (at least for debian/control), because it wouldn't make sense for a binary package's Architecture field to be 'any' or 'all' *plus* an explicit list of architectures. (yes, .dsc might need different rules, but.) My assumption is that however wrote this part of policy meant 'or' to be inclusive, not exclusive. Please reconsider your assumption :) Cheers, Julien -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530687: debian-policy: Please provide policy for architecture wildcards
On Wednesday 27 May 2009 07:49:09 Julien Cristau wrote: On Wed, May 27, 2009 at 07:30:57 -0400, Andres Mejia wrote: On Wednesday 27 May 2009 06:51:58 Julien Cristau wrote: This makes it sound like you can't mix architecture names and architecture wildcards. Is that on purpose? Current policy has this wording and I didn't want to change that, so yes, it's on purpose. Not quite. Current policy says arch list or 'any' or 'all' and that's fine (at least for debian/control), because it wouldn't make sense for a binary package's Architecture field to be 'any' or 'all' *plus* an explicit list of architectures. (yes, .dsc might need different rules, but.) Ok, here's the wording current policy. one may specify a list of architectures separated by spaces, or the special values any or all. Here's part of my proposal. one may specify a list of architectures separated by spaces, a list of architecture wildcards separated by spaces, or the special values any or all. What I'm trying to say is arch list or arch wildcards or 'any' or 'all', and judging by how current policy is written, I assume 'or' to mean inclusive OR, not XOR. My assumption is that however wrote this part of policy meant 'or' to be inclusive, not exclusive. Please reconsider your assumption :) Wrote that wrong. 's/however/whoever'. -- Regards, Andres -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530687: debian-policy: Please provide policy for architecture wildcards
On Wed, 2009-05-27 at 14:33 -0400, Andres Mejia wrote: Current policy has this wording and I didn't want to change that, so yes, it's on purpose. Not quite. Current policy says arch list or 'any' or 'all' and that's fine (at least for debian/control), because it wouldn't make sense for a binary package's Architecture field to be 'any' or 'all' *plus* an explicit list of architectures. (yes, .dsc might need different rules, but.) Ok, here's the wording current policy. one may specify a list of architectures separated by spaces, or the special values any or all. Here's part of my proposal. one may specify a list of architectures separated by spaces, a list of architecture wildcards separated by spaces, or the special values any or all. As a native english speaker that wording seems to me to imply (list of specific and/or wildcard architectures) or (any) or (all), which seems to be what you intend, but I guess it is open to possible misinterpretation in the manner Julien suggests. How about: ... a list of specific and wildcard architectures separated by spaces, or the special values 'any' or 'all'. Cheers, Andrew. Andrew @ McMillan .Net .NZ Porirua, New Zealand http://andrew.mcmillan.net.nz/Phone: +64(272)DEBIAN Open Source: the difference between trust and antitrust -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530687: debian-policy: Please provide policy for architecture wildcards
On Wednesday 27 May 2009 17:22:19 Andrew McMillan wrote: On Wed, 2009-05-27 at 14:33 -0400, Andres Mejia wrote: Current policy has this wording and I didn't want to change that, so yes, it's on purpose. Not quite. Current policy says arch list or 'any' or 'all' and that's fine (at least for debian/control), because it wouldn't make sense for a binary package's Architecture field to be 'any' or 'all' *plus* an explicit list of architectures. (yes, .dsc might need different rules, but.) Ok, here's the wording current policy. one may specify a list of architectures separated by spaces, or the special values any or all. Here's part of my proposal. one may specify a list of architectures separated by spaces, a list of architecture wildcards separated by spaces, or the special values any or all. As a native english speaker that wording seems to me to imply (list of specific and/or wildcard architectures) or (any) or (all), which seems to be what you intend, but I guess it is open to possible misinterpretation in the manner Julien suggests. How about: ... a list of specific and wildcard architectures separated by spaces, or the special values 'any' or 'all'. Or perhaps this: ... either a list of specific architectures and/or architecture wildcards separated by spaces, or the special values 'any' or 'all'. -- Regards, Andres -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 itemA unique single word identifying a Debian machine architecture, see ref id=arch-spec. + itemAn architecture wildcard identifying a set of Debian + machine architectures, see ref id=arch-wildcard-spec. itemttall/tt, which indicates an architecture-independent package. itemttany/tt, which indicates a package available @@ -2723,7 +2725,8 @@ Package: libc6 In the main filedebian/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 ttany/tt or + separated by spaces, a list of architecture wildcards separated by + spaces, or the special values ttany/tt or ttall/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 ttArchitecture/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 + (ttBuild-Depends/tt, ttBuild-Depends-Indep/tt, + ttBuild-Conflicts/tt and ttBuild-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 ttfoo/tt on any architecture in the Linux kernel, + ttbar/tt on any kernel on the i386 architecture, and ttbaz/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 + headingArchitecture Wildcards/heading + + p + A program may specify an architecture wildcard. Architecture + wildcards are in the format ttvaros/var/tt-any and + any-ttvararch/var/tt. Specifying an architecture wildcard + would be equivalent to specifying a list of architecture + specification strings provided by filedpkg-architecture -L/file + for a particular os or archictecture. + /p + + p + For example, specifying ttlinux-any/tt would be the same as + specifying ttarmel 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 ttany-i386/tt would be the same as specifying tti386 + kfreebsd-i386 knetbsd-i386 hurd-i386 darwin-i386 freebsd-i386 + netbsd-i386 openbsd-i386 solaris-i386/tt. + /p + /sect + sect headingDaemons/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)
Bug#530687: debian-policy: Please provide policy for architecture wildcards
I support this proposal, as written. Clearly this should have been in policy some time ago. Cheers, Andrew. On Tue, 2009-05-26 at 18:50 -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 itemA unique single word identifying a Debian machine architecture, see ref id=arch-spec. + itemAn architecture wildcard identifying a set of Debian + machine architectures, see ref id=arch-wildcard-spec. itemttall/tt, which indicates an architecture-independent package. itemttany/tt, which indicates a package available @@ -2723,7 +2725,8 @@ Package: libc6 In the main filedebian/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 ttany/tt or + separated by spaces, a list of architecture wildcards separated by + spaces, or the special values ttany/tt or ttall/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 ttArchitecture/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 + (ttBuild-Depends/tt, ttBuild-Depends-Indep/tt, + ttBuild-Conflicts/tt and ttBuild-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 ttfoo/tt on any architecture in the Linux kernel, + ttbar/tt on any kernel on the i386 architecture, and ttbaz/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 + headingArchitecture Wildcards/heading + + p + A program may specify an architecture wildcard. Architecture + wildcards are in the format ttvaros/var/tt-any and + any-ttvararch/var/tt. Specifying an architecture wildcard + would be equivalent to specifying a list of architecture + specification strings provided by filedpkg-architecture -L/file + for a particular os or archictecture. + /p + + p + For example, specifying ttlinux-any/tt would be the same as + specifying ttarmel 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 ttany-i386/tt would be the same as specifying tti386 + kfreebsd-i386 knetbsd-i386 hurd-i386 darwin-i386 freebsd-i386 + netbsd-i386 openbsd-i386 solaris-i386/tt. + /p + /sect + sect headingDaemons/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.
