Bug#530378: debian-policy: allow /usr/share/doc/package to point to another indirectly-depended-upon package's dir
On Mon, 25 May 2009, Serafeim Zanikolas wrote: On Sun, May 24, 2009 at 06:10:03PM -0700, Russ Allbery wrote: I guess I'm not understanding why you don't just make bogofilter depend on bogofilter-common as well. What's the drawback? None really, but it would seem as if we're making a technical decision for a bureaucratic reason, which doesn't seem right. The technical reason to do it this way is that it makes it much easier to test in lintian or similar; you just need to examine the target of the symlink and see if the package depends on the package named in the symlink target. [I'm not really sure where the bureaucracy is here.] Don Armstrong -- No matter how many instances of white swans we may have observed, this does not justify the conclusion that all swans are white. -- Sir Karl Popper _Logic of Scientific Discovery_ http://www.donarmstrong.com http://rzlab.ucr.edu -- 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 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
Re: Architecture in *.dsc files
On Wednesday 27 May 2009 00:04:19 Russ Allbery wrote: Jonathan Yu jonathan.i...@gmail.com writes: This is probably a stupid question, but... On Tue, May 26, 2009 at 11:33 PM, Russ Allbery r...@debian.org wrote: Currently, Policy's description of Architecture includes the statement: In the main debian/control file in the source package, or in the source package control file .dsc, one may specify a list of architectures separated by spaces, or the special values any or all. By my reading, this says that the Architecture field may be *either* a list of architectures *or* one of any or all. However, the current dpkg-dev appears to generate an Architecture line that includes both architectures and special values like all. I'm curious, which package(s) do this? What is the idea of doing so? Is it like saying, build specially on these architectures; otherwise just use 'all'? Or am I missing the point of it completely? I noticed it with the openafs package, whose compiled code only works with a restricted set of architectures but which also includes a documentation package that's arch: all. The Architecture field in the .dsc file isn't something that the package is responsible for. dpkg-dev creates it based on the Architecture fields in debian/control. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526617 appears to be the relevant change. I have no problem with this change -- it looks correct to me. It just means the Policy wording is wrong, and I'd rather get a definitive statement about what Policy *should* say and what the meaning of possible .dsc Architecture field contents are. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ Perhaps inclusive 'or' is meant here. That's the impression I get from reading this. Perhaps a footnote saying Here 'or' is meant inclusively should be added. -- 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
Re: Architecture in *.dsc files
Andres Mejia mcita...@gmail.com writes: Perhaps inclusive 'or' is meant here. That's the impression I get from reading this. Perhaps a footnote saying Here 'or' is meant inclusively should be added. Well, but that doesn't answer the more fundamental question. What does an Architecture field like: i386 amd64 all in a *.dsc file mean? Currently, Policy is silent here. Can any ever appear in combination with architectures (if, for example, the package builds some binary packages only on some architectures and others on all architectures)? The section also has some comma-splice problems and isn't clear in a few other ways, so with that information I'll probably rewrite it completely and try to make it clearer. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Architecture in *.dsc files
On Wed, 2009-05-27 at 11:19 -0700, Russ Allbery wrote:
Well, but that doesn't answer the more fundamental question. What does
an Architecture field like:
i386 amd64 all
in a *.dsc file mean? Currently, Policy is silent here.
That the binary packages referenced by the .dsc file include at least
one package that has Architecture: i386, at least one that has
Architecture: amd64 and at least one that has Architecture: all.
Can any ever appear in combination with architectures (if, for
example, the package builds some binary packages only on some
architectures and others on all architectures)?
From dpkg's point-of-view, the answer here appears to be no. The patch
introducing the feature includes this hunk:
+if (grep($_ eq 'any', @sourcearch)) {
+ # If we encounter one any then the other arches become insignificant.
+ @sourcearch = ('any');
+}
+$fields-{'Architecture'}= join(' ',@sourcearch);
Regards,
Adam
--
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
Re: Architecture in *.dsc files
On Wednesday 27 May 2009 14:19:02 Russ Allbery wrote: Andres Mejia mcita...@gmail.com writes: Perhaps inclusive 'or' is meant here. That's the impression I get from reading this. Perhaps a footnote saying Here 'or' is meant inclusively should be added. Well, but that doesn't answer the more fundamental question. What does an Architecture field like: i386 amd64 all in a *.dsc file mean? Currently, Policy is silent here. Can any ever appear in combination with architectures (if, for example, the package builds some binary packages only on some architectures and others on all architectures)? The section also has some comma-splice problems and isn't clear in a few other ways, so with that information I'll probably rewrite it completely and try to make it clearer. Looking at the code for sbuild [1], it seems that the Architecture is being used in the sense that policy should be written as, one may _either_ specify a list of architectures separated by spaces, or the special values any or all. I'm not sure if this is a problem with policy, or a problem with sbuild. 1. http://git.debian.org/?p=buildd- tools/sbuild.git;a=blob;f=lib/Sbuild/Build.pm;h=e171239d9e7326b6dd00c24c004faffd3b8f4b43;hb=ce5ef3dabd6a722e8cd515f0694c09343ec49bed#l539 -- 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
