Hi!
Quoting Guillem Jover (2014-11-10 19:48:33)
> And here it is, attached. Take into account as mentioned off-BTS, that the
> text regarding the default values for Build-Conflicts* does not currently
> match the implementation, but I'll be fixing this in a commit to be placed
> before this one.
>
> (Hmm, doing another quick check, I might rearrange the lists to mention
> real arch, "any" then "native" if relevant to be consistent.)
I don't fully understand your last comment in brackets but here is what I
thought (my comments apply to deb-control as well as deb-src-control):
> @@ -187,8 +187,16 @@ fields is a list of groups of alternative packages. Each
> group is a list
> of packages separated by vertical bar (or `pipe') symbols, `|'. The
> groups are separated by commas. Commas are to be read as `AND', and pipes
> as `OR', with pipes binding more tightly. Each package name is
> +optionally qualified with an architecture name appended after a colon ":",
It is not necessarily an "architecture name" that follows but also "any" or
"native". For clarity and to avoid ambiguity with below section I'd write:
'optionally followed by an architecture qualifier after a colon ":",'
or
'optionally qualified with an architecture name or "any" or "native"
appended after a colon ":"'
Since this is explained in the next paragraph, the former is probably the
better choice.
> optionally followed by a version number specification in parentheses.
> .LP
> +An architecture qualifier name can be \fBany\fP (since dpkg 1.16.2) or a
> +real Debian architecture name (since dpkg 1.16.5).
> +If omitted, the default is the current binary package architecture.
maybe say host or native architecture here? Maybe rather "native" because
"host" is more meaningful in the crossbuild context. Maybe there is an even
better way in dpkg speech. Is the native architecture not determined by the
architecture of dpkg itself?
> +A real Debian architecture name will match exactly that architecture for
> +that package name, \fBany\fP will match any architecture for that package
> +name.
maybe it should be noted that it is only meaningful to annotate dependencies on
Multi-Arch:allowed packages with :any?
> +.LP A version number may start with a `>>', in which case any later version
> will match, and may specify or omit the Debian packaging revision (separated
> by a hyphen). Accepted version relationships are ">>" for greater than,
>
> [...]
>
> diff --git a/man/deb-src-control.5 b/man/deb-src-control.5
> index 665dced..ae99f47 100644
> --- a/man/deb-src-control.5
> +++ b/man/deb-src-control.5
>
> [...]
>
> @@ -202,6 +203,15 @@ parentheses, an architecture specification in square
> brackets, and a
> restriction formula consisting of one or more lists of profile names in
> angle brackets.
> +An architecture qualifier name can be \fBany\fP (since dpkg 1.16.2),
> +\fBnative\fP (since 1.16.5) or a real Debian architecture name (since
> +dpkg 1.16.5).
> +If omitted, the default for \fBBuild\-Depends\fP fields is the current host
> +architecture, the default for \fBBuild\-Conflicts\fP fields is \fBany\fP.
> +A real Debian architecture name will match exactly that architecture for
> +that package name, \fBany\fP will match any architecture for that package
> +name, and \fBnative\fP will match the current build architecture.
As above, maybe mention that :any only makes sense to annotate M-A:allowed
packages with and :native is disallowed for M-A:foreign packages. But maybe
this is too much for this man page.
Thanks!
cheers, josch
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
