Debian Bug report logs - #593909
clarify the syntax of Debian control files

version graph

Package: debian-policy; Maintainer for debian-policy is Debian Policy List <debian-policy@lists.debian.org>; Source for debian-policy is src:debian-policy.

Reported by: Charles Plessy <plessy@debian.org>

Date: Sun, 22 Aug 2010 06:24:02 UTC

Severity: wishlist

Merged with 618013

Found in version debian-policy/3.9.1.0

Fixed in version debian-policy/3.9.2.0

Done: Russ Allbery <rra@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, plessy@debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Sun, 22 Aug 2010 06:24:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Charles Plessy <plessy@debian.org>:
New Bug report received and forwarded. Copy sent to plessy@debian.org, Debian Policy List <debian-policy@lists.debian.org>. (Sun, 22 Aug 2010 06:24:04 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Charles Plessy <plessy@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: debian-policy: Clarifications about the syntax of Debian control files.
Date: Sun, 22 Aug 2010 15:23:26 +0900
Package: debian-policy
Version: 3.9.1.0
Severity: wishlist

Dear all,

I have been reading §5.1 (Syntax of control files) many times recently, and
would like propose clarifications about a couple of points. If consensus emerges,
I will write a patch.


Non-wrappable field values
--------------------------

§5.1 contains the following paragraph:

  In fields where it is specified that lines may not wrap, only a single line of
  data is allowed and whitespace is not significant in a field body. Whitespace
  must not appear inside names (of packages, architectures, files or anything
  else) or version numbers, or between the characters of multi-character version
  relationships.

The Architecture and Closes fields seem to follow this convention, without
referring to it (they do not specify that ‘lines may not wrap’). The
Distribution also allows a list of values, but not for the Debian archive.
The Binary field also contains a space-separated list of items, but is
wrappable.

Many other fields are single line, but they do not contain a list of
space-separated items. For instance, the Maintainer and Urgencey fields.

Policy chapter 5 contains only two times the word “wrap”, one in the above
quotation and one in the context of the Description field (§5.6.13), in the
part that explain how to specify verbatim parts in extened descriptions.

There are other possible interpretations of the paragraph I cited above, but I
could not find a field that would fit with them.

I am working on DEP-5, which aims at using the Debian control file format, I
have the feeling that the paragraph that I quoted above makes it more difficult
to describe how text can be wrapped or not on multi-line fields. Unless it has
a crucial role that I have overlooked, I propose its supppression. 


Ordering of the paragraphs
--------------------------

I always had the impression that the Debian control files had one header
paragraph, followed by other paragraphs that were not ordered. If it is not the
case, that is: if parsers are required to remember the order of the paragraphs.
I think that it would be useful to write it in §5.1.


Line escape and paragraph separators
------------------------------------

“Blank lines, or lines consisting only of spaces and tabs, are not allowed
within field values or between fields”. The Description and Changes fields
introduce a convention to escape blank lines, representing them by a space
followed by a dot. How describing this convention directly in §5.1?

Also, while submitting this bug, I found #501930 about paragraph separation.
If the outcome of this discussion is a patch, I propose to let it addres
#501930 as well, by adding “lines consisting only of spaces and tabs” to the
second sentence of §5.1.


Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Thu, 26 Aug 2010 01:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Charles Plessy <plessy@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Thu, 26 Aug 2010 01:09:03 GMT) Full text and rfc822 format available.

Message #10 received at 593909@bugs.debian.org (full text, mbox):

From: Charles Plessy <plessy@debian.org>
To: 593909@bugs.debian.org
Subject: Re: debian-policy: Clarifications about the syntax of Debian control files.
Date: Thu, 26 Aug 2010 10:05:17 +0900
Le Sun, Aug 22, 2010 at 03:23:26PM +0900, Charles Plessy a écrit :
> 
> 
> I have been reading §5.1 (Syntax of control files) many times recently, and
> would like propose clarifications about a couple of points. If consensus emerges,
> I will write a patch.
> 
> 
> Non-wrappable field values
 
> Ordering of the paragraphs
 
> Line escape and paragraph separators

Hi again,

to this list I would like to add comment lines. Currently they are described in
§5.2 (5.2 Source package control files -- debian/control), as an additional
syntax, which strongly suggests that they are allowed in this file only.
Independantly of whether this is confirmed or not, this syntactic information
would rather belong to §5.1, that defines the syntax of the control files,
instead of §5.2, which like the next chapters §5.3–6 lists the fields allowed
in the different Debian control files. I would therefore propose to have in
§5.1:

  Lines starting with # without any preceding whitespace are ‘comments lines’
  and are ignored, even in the middle of continuation lines for a multiline
  field. They do not end a multiline field.

If comment lines are only allowed in source package control files, we could
add:

  The use of such comments must be allowed on a per-file basis.

And then in §5.2:

  Comment lines are allowed.

The benefit of this is that it concentrates in §5.1 all the instructions to
write a basic parser for Debian control files.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Thu, 26 Aug 2010 03:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andrew McMillan <andrew@morphoss.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Thu, 26 Aug 2010 03:42:03 GMT) Full text and rfc822 format available.

Message #15 received at 593909@bugs.debian.org (full text, mbox):

From: Andrew McMillan <andrew@morphoss.com>
To: Charles Plessy <plessy@debian.org>, 593909@bugs.debian.org
Subject: Re: Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.
Date: Thu, 26 Aug 2010 15:38:42 +1200
[Message part 1 (text/plain, inline)]
On Thu, 2010-08-26 at 10:05 +0900, Charles Plessy wrote:
> Le Sun, Aug 22, 2010 at 03:23:26PM +0900, Charles Plessy a écrit :
> > 
> > 
> > I have been reading §5.1 (Syntax of control files) many times recently, and
> > would like propose clarifications about a couple of points. If consensus emerges,
> > I will write a patch.
> > 
> > 
> > Non-wrappable field values
>  
> > Ordering of the paragraphs
>  
> > Line escape and paragraph separators
> 
> Hi again,
> 
> to this list I would like to add comment lines. Currently they are described in
> §5.2 (5.2 Source package control files -- debian/control), as an additional
> syntax, which strongly suggests that they are allowed in this file only.
> Independantly of whether this is confirmed or not, this syntactic information
> would rather belong to §5.1, that defines the syntax of the control files,
> instead of §5.2, which like the next chapters §5.3–6 lists the fields allowed
> in the different Debian control files. I would therefore propose to have in
> §5.1:
> 
>   Lines starting with # without any preceding whitespace are ‘comments lines’
>   and are ignored, even in the middle of continuation lines for a multiline
>   field. They do not end a multiline field.
> 
> If comment lines are only allowed in source package control files, we could
> add:
> 
>   The use of such comments must be allowed on a per-file basis.
> 
> And then in §5.2:
> 
>   Comment lines are allowed.
> 
> The benefit of this is that it concentrates in §5.1 all the instructions to
> write a basic parser for Debian control files.

This seems sensible, and I think all of the clarifications you plan are
in the same light, and I would certainly support a patch expressing this
all more clearly.

Cheers,
					Andrew.

-- 
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com                            +64(272)DEBIAN
    I have not seen high-discipline processes succeed in commercial
                     settings. - Alistair Cockburn

------------------------------------------------------------------------

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Fri, 27 Aug 2010 17:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 27 Aug 2010 17:27:03 GMT) Full text and rfc822 format available.

Message #20 received at 593909@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Charles Plessy <plessy@debian.org>
Cc: 593909@bugs.debian.org
Subject: Re: Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.
Date: Fri, 27 Aug 2010 10:24:57 -0700
Charles Plessy <plessy@debian.org> writes:

> Non-wrappable field values
> --------------------------

> §5.1 contains the following paragraph:

>   In fields where it is specified that lines may not wrap, only a single
>   line of data is allowed and whitespace is not significant in a field
>   body. Whitespace must not appear inside names (of packages,
>   architectures, files or anything else) or version numbers, or between
>   the characters of multi-character version relationships.

What this paragraph means by "wrap" is "may span multiple lines," and it's
also really not correct about whitespace.  I think what this paragraph
should say is something like:

    In fields where the value may not span multiple lines, the amount of
    whitespace in the field body is not significant.  Any amount of
    whitespace is equivalent to a single space.  Whitespace must not
    appear inside names (of packages, architectures, files, or anything
    else) or version numbers, or between the characters of multi-character
    versoin relationships.

> The Architecture and Closes fields seem to follow this convention,
> without referring to it (they do not specify that ‘lines may not
> wrap’). The Distribution also allows a list of values, but not for the
> Debian archive.  The Binary field also contains a space-separated list
> of items, but is wrappable.

"Wrap" is a very bad term to use here, since it implies something about
presentation.  That's not the intention of the paragraph; rather, it's
talking about whether or not the field body may contain newlines.

> Many other fields are single line, but they do not contain a list of
> space-separated items. For instance, the Maintainer and Urgencey fields.

Indeed.  But I don't think we imply that it does.

> Policy chapter 5 contains only two times the word “wrap”, one in the
> above quotation and one in the context of the Description field
> (§5.6.13), in the part that explain how to specify verbatim parts in
> extened descriptions.

The second use is correct, and we should definitely fix the first.

> I am working on DEP-5, which aims at using the Debian control file
> format, I have the feeling that the paragraph that I quoted above makes
> it more difficult to describe how text can be wrapped or not on
> multi-line fields. Unless it has a crucial role that I have overlooked,
> I propose its supppression.

It's saying a bunch of things that aren't said elsewhere, so I don't think
there's any way that we could just drop it.

> Ordering of the paragraphs
> --------------------------

> I always had the impression that the Debian control files had one header
> paragraph, followed by other paragraphs that were not ordered. If it is
> not the case, that is: if parsers are required to remember the order of
> the paragraphs.  I think that it would be useful to write it in §5.1.

In that case, yes, we should say that the order of paragraphs is
significant, since indeed it always has been.  Probably just by adding the
sentence "The order of paragraphs in the control file is significant" to
the end of the first paragraph.

> Line escape and paragraph separators
> ------------------------------------

> “Blank lines, or lines consisting only of spaces and tabs, are not
> allowed within field values or between fields”. The Description and
> Changes fields introduce a convention to escape blank lines,
> representing them by a space followed by a dot. How describing this
> convention directly in §5.1?

Sure, that sounds like a good idea.

> Also, while submitting this bug, I found #501930 about paragraph
> separation.  If the outcome of this discussion is a patch, I propose to
> let it addres #501930 as well, by adding “lines consisting only of
> spaces and tabs” to the second sentence of §5.1.

I'm torn on that bug.  The ideal thing to do there, I think, is to say
that lines consisting solely of spaces and tabs are a syntax error and are
not allowed, but parsers may accept them as paragraph separators.  (Be
conservative in what you generate and liberal in what you accept.)  I'm
concerned that we have code out there that doesn't recognize them as
paragraph separators, and explicitly allowing them will make that code
buggy.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Fri, 27 Aug 2010 17:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 27 Aug 2010 17:30:03 GMT) Full text and rfc822 format available.

Message #25 received at 593909@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Charles Plessy <plessy@debian.org>
Cc: 593909@bugs.debian.org
Subject: Re: Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.
Date: Fri, 27 Aug 2010 10:26:50 -0700
Charles Plessy <plessy@debian.org> writes:

> to this list I would like to add comment lines. Currently they are
> described in §5.2 (5.2 Source package control files -- debian/control),
> as an additional syntax, which strongly suggests that they are allowed
> in this file only.

That's correct; they're only allowed in source package control files.

> Independantly of whether this is confirmed or not, this syntactic
> information would rather belong to §5.1, that defines the syntax of the
> control files, instead of §5.2, which like the next chapters §5.3–6
> lists the fields allowed in the different Debian control files. I would
> therefore propose to have in §5.1:

>   Lines starting with # without any preceding whitespace are ‘comments
>   lines’ and are ignored, even in the middle of continuation lines for a
>   multiline field. They do not end a multiline field.

> If comment lines are only allowed in source package control files, we could
> add:

>   The use of such comments must be allowed on a per-file basis.

I would rather just say "These comments are only permitted in source
package control files (<file>debian/control</file>)," and preferrably say
that as the first sentence of the paragraph rather than the last.  I can't
imagine us ever adding support for them anywhere else.

> And then in §5.2:

>   Comment lines are allowed.

This is fine.

> The benefit of this is that it concentrates in §5.1 all the instructions
> to write a basic parser for Debian control files.

Yes, that's a good idea.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Fri, 27 Aug 2010 19:03:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Bernhard R. Link" <brlink@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 27 Aug 2010 19:03:06 GMT) Full text and rfc822 format available.

Message #30 received at 593909@bugs.debian.org (full text, mbox):

From: "Bernhard R. Link" <brlink@debian.org>
To: 593909@bugs.debian.org
Subject: Re: Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.
Date: Fri, 27 Aug 2010 21:01:48 +0200
* Russ Allbery <rra@debian.org> [100827 19:27]:
> I'm torn on that bug.  The ideal thing to do there, I think, is to say
> that lines consisting solely of spaces and tabs are a syntax error and are
> not allowed, but parsers may accept them as paragraph separators.  (Be
> conservative in what you generate and liberal in what you accept.)

I'd rather see if it encourages parsers to error out in those cases
(Fail early, fail often). If something accepts them because they cannot
propagate the error properly that is no big problem. But if too many
allow them they will get used and there will definitly be code that has
problems because there is simply no way to test all those different
cases.

	Bernhard R. Link




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Fri, 27 Aug 2010 23:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 27 Aug 2010 23:15:03 GMT) Full text and rfc822 format available.

Message #35 received at 593909@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 593909@bugs.debian.org
Subject: Re: Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.
Date: Fri, 27 Aug 2010 16:13:06 -0700
Ben Finney <ben+debian@benfinney.id.au> writes:
> Russ Allbery <rra@debian.org> writes:

>> In that case, yes, we should say that the order of paragraphs is
>> significant, since indeed it always has been. Probably just by adding
>> the sentence "The order of paragraphs in the control file is
>> significant" to the end of the first paragraph.

> The source package stanza must come first, I can see why that's
> significant. But why does the order of binary package stanzas matter?

debhelper(7):

       Note that if a package is the first (or only) binary package listed
       in debian/control, debhelper will use debian/foo if no
       debian/package.foo file can be found.

Also, dh_listpackages returns them in control-file order and some source
packages do rely on this.  CDBS-based packages, last time I touched CDBS,
required listing shared library packages before binary packages that used
them in order for dh_shlibdeps to produce the correct results due to how
the packages were constructed (otherwise, dh_makeshlibs for the shared
library package wouldn't have run before dh_shlibdeps for the binary
package).  I've seen other examples.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Sat, 28 Aug 2010 20:36:21 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 28 Aug 2010 20:36:21 GMT) Full text and rfc822 format available.

Message #40 received at 593909@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 593909@bugs.debian.org
Subject: Re: Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.
Date: Sat, 28 Aug 2010 13:34:35 -0700
Charles Plessy <plessy@debian.org> writes:
> Le Fri, Aug 27, 2010 at 10:24:57AM -0700, Russ Allbery a écrit :

>> What this paragraph means by "wrap" is "may span multiple lines," and
>> it's also really not correct about whitespace.  I think what this
>> paragraph should say is something like:

>>     In fields where the value may not span multiple lines, the amount
>>     of whitespace in the field body is not significant.  Any amount of
>>     whitespace is equivalent to a single space.  Whitespace must not
>>     appear inside names (of packages, architectures, files, or anything
>>     else) or version numbers, or between the characters of
>>     multi-character versoin relationships.

> I still have difficulties to understand the meaning of this paragraph,
> and to what fields it applies. Is it just specifiying that the parser,
> in the case of fields that allow continuation lines, can be either
> intructed to replace all white spaces and newlines by single spaces, or
> to leave the value as it is, including the new lines?

No, it's really trying to say that the amount of whitespace isn't
significant.  I'm not sure how else to explain it.  That's one of those
precise terms of art for which there isn't really an acceptable synonym,
at least not that I can think of.  Replacing all whitespace with a single
space is one of the things that you can do *because* the amount of
whitespace is not significant, but it's not an equivalent statement.

> In that case I would propose the following wording.

> 	  The field's description may speficy whether continuation lines
> 	  are allowed or not.

The phrase "span multiple lines" needs to stay.

> 	  When continuation lines are allowed, the field's value contains
> 	  the newlines characters of the continuation lines.

I think that's a confusing way of saying that whitespace other than
leading and trailing whitespace is significant in fields that span
multiple lines.  I'd rather just say it that way.

> 	  In that case, whitespace must not appear inside names (of
> 	  packages, architectures, files, or anything else) or version
> 	  numbers, or between the characters of multi-character version
> 	  relationships.

That raises another issue: this is not specific to fields that cannot span
multiple lines.  This is true of all fields.  We should make this a
separate paragraph to make that more obvious.

> I have one more question: are continuation lines disallowed unless
> specified otherwise?

Yes.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Sun, 29 Aug 2010 11:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to PJ Weisberg <pj@irregularexpressions.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 29 Aug 2010 11:27:03 GMT) Full text and rfc822 format available.

Message #45 received at 593909@bugs.debian.org (full text, mbox):

From: PJ Weisberg <pj@irregularexpressions.net>
To: 593909@bugs.debian.org
Subject: Re: Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.
Date: Sun, 29 Aug 2010 04:17:40 -0700
On Sat, Aug 28, 2010 at 1:34 PM, Russ Allbery <rra@debian.org> wrote:
> Charles Plessy <plessy@debian.org> writes:
>> Le Fri, Aug 27, 2010 at 10:24:57AM -0700, Russ Allbery a écrit :
>>
>>>     In fields where the value may not span multiple lines, the amount
>>>     of whitespace in the field body is not significant.  Any amount of
>>>     whitespace is equivalent to a single space.  Whitespace must not
>>>     appear inside names (of packages, architectures, files, or anything
>>>     else) or version numbers, or between the characters of
>>>     multi-character versoin relationships.
>
>> I still have difficulties to understand the meaning of this paragraph,
>> and to what fields it applies. Is it just specifiying that the parser,
>> in the case of fields that allow continuation lines, can be either
>> intructed to replace all white spaces and newlines by single spaces, or
>> to leave the value as it is, including the new lines?
>
> No, it's really trying to say that the amount of whitespace isn't
> significant.  I'm not sure how else to explain it.  That's one of those
> precise terms of art for which there isn't really an acceptable synonym,
> at least not that I can think of.  Replacing all whitespace with a single
> space is one of the things that you can do *because* the amount of
> whitespace is not significant, but it's not an equivalent statement.

It might be more *precise* to say that the field contains a series of
whitespace-delimited tokens, but I don't know if that would be more
*understandable*.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Sun, 29 Aug 2010 12:06:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andrew McMillan <andrew@morphoss.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 29 Aug 2010 12:06:05 GMT) Full text and rfc822 format available.

Message #50 received at 593909@bugs.debian.org (full text, mbox):

From: Andrew McMillan <andrew@morphoss.com>
To: PJ Weisberg <pj@irregularexpressions.net>, 593909@bugs.debian.org
Subject: Re: Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.
Date: Mon, 30 Aug 2010 00:01:57 +1200
[Message part 1 (text/plain, inline)]
On Sun, 2010-08-29 at 04:17 -0700, PJ Weisberg wrote:
> On Sat, Aug 28, 2010 at 1:34 PM, Russ Allbery <rra@debian.org> wrote:
> > Charles Plessy <plessy@debian.org> writes:
> >> Le Fri, Aug 27, 2010 at 10:24:57AM -0700, Russ Allbery a écrit :
> >>
> >>>     In fields where the value may not span multiple lines, the amount
> >>>     of whitespace in the field body is not significant.  Any amount of
> >>>     whitespace is equivalent to a single space.  Whitespace must not
> >>>     appear inside names (of packages, architectures, files, or anything
> >>>     else) or version numbers, or between the characters of
> >>>     multi-character version relationships.
> >
> >> I still have difficulties to understand the meaning of this paragraph,
> >> and to what fields it applies. Is it just specifiying that the parser,
> >> in the case of fields that allow continuation lines, can be either
> >> instructed to replace all white spaces and newlines by single spaces, or
> >> to leave the value as it is, including the new lines?
> >
> > No, it's really trying to say that the amount of whitespace isn't
> > significant.  I'm not sure how else to explain it.  That's one of those
> > precise terms of art for which there isn't really an acceptable synonym,
> > at least not that I can think of.  Replacing all whitespace with a single
> > space is one of the things that you can do *because* the amount of
> > whitespace is not significant, but it's not an equivalent statement.
> 
> It might be more *precise* to say that the field contains a series of
> whitespace-delimited tokens, but I don't know if that would be more
> *understandable*.

Given the target audience (i.e. the ornery DD :-) it seems likely to me
that they would then want to know if those tokens can be quoted strings.

The above text seems to me to remove the possibility of that
question :-)

Sure it's maybe a little wordy, but it's explicit also,and not too
unreadable.

Cheers,
					Andrew.

-- 
------------------------------------------------------------------------
http://andrew.mcmillan.net.nz/                     Porirua, New Zealand
Twitter: _karora                                  Phone: +64(272)DEBIAN
           Time to be aggressive.  Go after a tattooed Virgo.
------------------------------------------------------------------------

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Fri, 03 Sep 2010 01:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Charles Plessy <plessy@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 03 Sep 2010 01:39:03 GMT) Full text and rfc822 format available.

Message #55 received at 593909@bugs.debian.org (full text, mbox):

From: Charles Plessy <plessy@debian.org>
To: 593909@bugs.debian.org
Subject: Re: Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.
Date: Fri, 3 Sep 2010 10:36:21 +0900
[Message part 1 (text/plain, inline)]
Le Sat, Aug 28, 2010 at 01:34:35PM -0700, Russ Allbery a écrit :
> Charles Plessy <plessy@debian.org> writes:
> > Le Fri, Aug 27, 2010 at 10:24:57AM -0700, Russ Allbery a écrit :
> 
> >>     In fields where the value may not span multiple lines, the amount
> >>     of whitespace in the field body is not significant.  Any amount of
> >>     whitespace is equivalent to a single space.  Whitespace must not
> >>     appear inside names (of packages, architectures, files, or anything
> >>     else) or version numbers, or between the characters of
> >>     multi-character versoin relationships.
> 
> > I still have difficulties to understand the meaning of this paragraph,
> > and to what fields it applies. Is it just specifiying that the parser,
> > in the case of fields that allow continuation lines, can be either
> > intructed to replace all white spaces and newlines by single spaces, or
> > to leave the value as it is, including the new lines?
> 
> No, it's really trying to say that the amount of whitespace isn't
> significant.  I'm not sure how else to explain it.  That's one of those
> precise terms of art for which there isn't really an acceptable synonym,
> at least not that I can think of.  Replacing all whitespace with a single
> space is one of the things that you can do *because* the amount of
> whitespace is not significant, but it's not an equivalent statement.

Dear Russ and everybody

since I was still confused, I comprehensively inspected the wordings in
chapter 5, to better understand what is meant by ’span multiple lines’.

First, as a sidenote, no field specifies that it may not span multiple lines. I
therefore agree with you that it is an implicit default case, and propose to
make it explicit in § 5.1 (see below).

I then looked at which field description specifies that they ‘may span multiple
lines’. These are the relationship fields (Depends etc., §7.1), the Binary
field, and the Uploaders field, but only in source package control files. The
Files and Checksums-* fields, on the other hand are described as ‘multiline
fields’. Lastly, nothing is specified for the Description and Changes fields,
perhaps because it is so obvious.

It looks like ‘may span multiple lines’ means that continuation lines are
allowed but newlines are not significant, and ‘multiline fields’ means that
continuation lines are allowed and newlines are significant. At this point, I
am not sure what is expected from the parsers: deliver the value of the fields
that ‘may span multiple lines’ with or without newlines? In any casee, I find
this similarity of terminology very confusing. I therefore propose to replace
‘may span multiple lines’ by ‘continuation lines are allowed’ and add it where
it was implicit, and add ‘continuation lines are allowed and newlines are
significant’ where needed as well.

I noted another confusing sentence on the subject, in §5.2: ‘Many fields are
permitted to span multiple lines in <file>debian/control</file> but not in any
other control file’. Actually, I found this to be true only for the Uploaders
field. I propose to replace it by ‘Continuation lines can be permitted for some
fields in <file>debian/control</file> but not in any other control file.’

Together with the separation that you suggested in your answer, the rewording
that I propose allows to dramaticly slim down—and in my opinion, clarify—the
paragraph that discusses mulitple line spanning and whitespace:

        <p>
	  Continuation lines need to be allowed for each field separately.
	  When continuation lines are allowed, whitespace including newlines
	  is not significant in the fields values, unless specified otherwise.
        </p>

        <p>
          Whitespace must not appear
          inside names (of packages, architectures, files or anything
          else) or version numbers, or between the characters of
          multi-character version relationships.
        </p>

This would need to be changed if the parser is expected to deliver the field's
value with the newlines already stripped, except for fields where whitespace is
speficied to be significant. Note that in all cases the trailing whitespace of
a continuation line is not included in field values, since they are removed as
part of the parsing of the continuation lines.

I attached a patch that tries to summarise the above and the points discussed
in other messages of this thread. It also includes a minor correction for the
Essential field, to bring it in line with the nomenclature used in this
chapter.  I also tried to replace occurences of ‘wrap’ and ‘span’ by less
ambiguous words.


Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan
[0001-Clarifications-on-the-syntax-of-control-fields.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Fri, 03 Sep 2010 01:57:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 03 Sep 2010 01:57:02 GMT) Full text and rfc822 format available.

Message #60 received at 593909@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Charles Plessy <plessy@debian.org>
Cc: 593909@bugs.debian.org
Subject: Re: Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.
Date: Thu, 02 Sep 2010 18:52:15 -0700
Charles Plessy <plessy@debian.org> writes:

> First, as a sidenote, no field specifies that it may not span multiple
> lines. I therefore agree with you that it is an implicit default case,
> and propose to make it explicit in § 5.1 (see below).

Agreed.

> I then looked at which field description specifies that they ‘may span
> multiple lines’. These are the relationship fields (Depends etc., §7.1),
> the Binary field, and the Uploaders field, but only in source package
> control files. The Files and Checksums-* fields, on the other hand are
> described as ‘multiline fields’. Lastly, nothing is specified for the
> Description and Changes fields, perhaps because it is so obvious.

> It looks like ‘may span multiple lines’ means that continuation lines
> are allowed but newlines are not significant, and ‘multiline fields’
> means that continuation lines are allowed and newlines are
> significant. At this point, I am not sure what is expected from the
> parsers: deliver the value of the fields that ‘may span multiple lines’
> with or without newlines? In any casee, I find this similarity of
> terminology very confusing. I therefore propose to replace ‘may span
> multiple lines’ by ‘continuation lines are allowed’ and add it where it
> was implicit, and add ‘continuation lines are allowed and newlines are
> significant’ where needed as well.

Agreed.  This is very confusing right now, and I think your proposed
method of rephrasing is a good one.  Although another approach may be to
introduce the folding terminology from RFC 5322.

The distinction really is that some fields can be folded (Build-*, for
example) and some fields are multi-line (Description, Files).  The
multi-line fields are not folded in the RFC 5322 sense, since you cannot
just remove the newlines and have semantically the same content.  Those
fields (Description, Files) are a separate type of field that RFC 5322
doesn't have.

> I noted another confusing sentence on the subject, in §5.2: ‘Many fields
> are permitted to span multiple lines in <file>debian/control</file> but
> not in any other control file’. Actually, I found this to be true only
> for the Uploaders field.

I believe this is true of all binary relationship fields and all build
relationship fields as well.  The dpkg-dev tools unfold all of those
fields when generating *.dsc, *.changes, and DEBIAN/control files, and
parers of those generated files do not have to cope with folded fields
(and I believe are known *not* to be able to cope with folded fields in
some cases).  We should say that explicitly.

> I propose to replace it by ‘Continuation lines can be permitted for some
> fields in <file>debian/control</file> but not in any other control
> file.’

Sounds okay to me with the above note about possibly wanting to use
folding instead.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Sat, 04 Sep 2010 12:51:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 04 Sep 2010 12:51:05 GMT) Full text and rfc822 format available.

Message #65 received at 593909@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: 593909@bugs.debian.org
Subject: Re: Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.
Date: Sat, 4 Sep 2010 14:48:23 +0200
On Thu, 02 Sep 2010, Russ Allbery wrote:
> I believe this is true of all binary relationship fields and all build
> relationship fields as well.  The dpkg-dev tools unfold all of those
> fields when generating *.dsc, *.changes, and DEBIAN/control files, and
> parers of those generated files do not have to cope with folded fields
> (and I believe are known *not* to be able to cope with folded fields in
> some cases).  We should say that explicitly.

Just a minor remark: we modified policy not so long ago to allow the
Binary field to be folded even in .dsc and .changes.

So your assertion is not always true.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Sat, 04 Sep 2010 22:57:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 04 Sep 2010 22:57:03 GMT) Full text and rfc822 format available.

Message #70 received at 593909@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 593909@bugs.debian.org
Subject: Re: Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.
Date: Sat, 04 Sep 2010 15:54:32 -0700
Raphael Hertzog <hertzog@debian.org> writes:
> On Thu, 02 Sep 2010, Russ Allbery wrote:

>> I believe this is true of all binary relationship fields and all build
>> relationship fields as well.  The dpkg-dev tools unfold all of those
>> fields when generating *.dsc, *.changes, and DEBIAN/control files, and
>> parers of those generated files do not have to cope with folded fields
>> (and I believe are known *not* to be able to cope with folded fields in
>> some cases).  We should say that explicitly.

> Just a minor remark: we modified policy not so long ago to allow the
> Binary field to be folded even in .dsc and .changes.

> So your assertion is not always true.

I don't see any contradiction between what you said and what I said, so
I'm not sure what assertion you're disagreeing with.  The Binary field is
not a binary or build relationship field.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Sun, 05 Sep 2010 08:45:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 05 Sep 2010 08:45:03 GMT) Full text and rfc822 format available.

Message #75 received at 593909@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Russ Allbery <rra@debian.org>, 593909@bugs.debian.org
Subject: Re: Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.
Date: Sun, 5 Sep 2010 10:41:12 +0200
On Sat, 04 Sep 2010, Russ Allbery wrote:
> Raphael Hertzog <hertzog@debian.org> writes:
> > On Thu, 02 Sep 2010, Russ Allbery wrote:
> 
> >> I believe this is true of all binary relationship fields and all build
> >> relationship fields as well.  The dpkg-dev tools unfold all of those
> >> fields when generating *.dsc, *.changes, and DEBIAN/control files, and
> >> parers of those generated files do not have to cope with folded fields
> >> (and I believe are known *not* to be able to cope with folded fields in
> >> some cases).  We should say that explicitly.
> 
> > Just a minor remark: we modified policy not so long ago to allow the
> > Binary field to be folded even in .dsc and .changes.
> 
> > So your assertion is not always true.
> 
> I don't see any contradiction between what you said and what I said, so
> I'm not sure what assertion you're disagreeing with.  The Binary field is
> not a binary or build relationship field.

Right, I've read your sentence too quickly, sorry.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Sat, 11 Sep 2010 14:51:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Charles Plessy <plessy@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 11 Sep 2010 14:51:04 GMT) Full text and rfc822 format available.

Message #80 received at 593909@bugs.debian.org (full text, mbox):

From: Charles Plessy <plessy@debian.org>
To: 593909@bugs.debian.org
Subject: Re: Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.
Date: Sat, 11 Sep 2010 23:45:55 +0900
[Message part 1 (text/plain, inline)]
Le Thu, Sep 02, 2010 at 06:52:15PM -0700, Russ Allbery a écrit :
> 
> The distinction really is that some fields can be folded (Build-*, for
> example) and some fields are multi-line (Description, Files).  The
> multi-line fields are not folded in the RFC 5322 sense, since you cannot
> just remove the newlines and have semantically the same content.  Those
> fields (Description, Files) are a separate type of field that RFC 5322
> doesn't have.

I think that it is an excellent idea to use the vocabulary of the RFC. It has
been written many times that the control files follow the syntax of the RFC 822
and its successors, and I think that it would help to show where this is true
and where it is not.

In the attached patch, I refer to the RFC 2822: isn't 5322 a draft ? Also, I
integrated your comment about the relationships fields, that can not be folded
elsewhere than in source package files.

The attached patch also contains the (corrected) addition of the
DM-Upload-Allowed field.

I wonder if it would be worthwile to add the Bugs and Origin fields as well.

Have a nice Sunday,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan
[clarifications-control-fields.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Sun, 19 Sep 2010 04:51:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 19 Sep 2010 04:51:05 GMT) Full text and rfc822 format available.

Message #85 received at 593909@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Charles Plessy <plessy@debian.org>
Cc: 593909@bugs.debian.org
Subject: Re: Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.
Date: Sat, 18 Sep 2010 21:46:41 -0700
Charles Plessy <plessy@debian.org> writes:

> I think that it is an excellent idea to use the vocabulary of the
> RFC. It has been written many times that the control files follow the
> syntax of the RFC 822 and its successors, and I think that it would help
> to show where this is true and where it is not.

> In the attached patch, I refer to the RFC 2822: isn't 5322 a draft ?

There are three stages to the IETF standards process: Proposed Standard,
Draft Standard, and Standard (or "full standard").  Documents can only
advance along this track if there are no substantive changes (with some
specific exceptions), so any major revision reverts back to Proposed and
has to go through those steps.

The only full Standard for the format is RFC 822, but it's widely
considered obsolete.  RFC 2822 was the Proposed Standard to replace and
update it, and RFC 5322 is the Draft Standard advancement of RFC 2822.

If one is very conservative, one may still want to refer to RFC 822
instead of the successors since its successors have not yet reached full
standard, but it's always wrong at this point to refer to RFC 2822 in
preference to RFC 5322, since the latter is one step farther down the
acceptance process than the former and has only "bug fixes" relative to
2822.

> The attached patch also contains the (corrected) addition of the
> DM-Upload-Allowed field.

I've since merged this separately, so an updated patch with fixes to the
above and rebased against the current repository would be good.  (In
general, please don't combine different issues into one patch.  Git should
hopefully make it relatively easy to juggle multiple branches.)

> I wonder if it would be worthwile to add the Bugs and Origin fields as
> well.

I don't think so, since neither should be set for any packages in the
Debian archive.  They're more of a dpkg feature intended for non-Debian
packages.

> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -2449,19 +2449,22 @@ endif
>  	  fields<footnote>
>  		The paragraphs are also sometimes referred to as stanzas.
>  	  </footnote>.
> -	  The paragraphs are separated by blank lines.  Some control
> +	  The paragraphs are separated by empty lines.  As a special exception
> +	  for backwards compatibility, parsers may accept lines consisting
> +	  solely of spaces and tabs as paragraph separators. Some control

I don't think it's a big deal, but I'd phrase this sentence as:

    Parsers may accept lines consisting solely of spaces and tabs as
    paragraph separators, but control files should use empty lines.

I don't think the compatibility is for backward compatibility as much as
because it's easy to do this by accident.

>  	  files allow only one paragraph; others allow several, in
>  	  which case each paragraph usually refers to a different
>  	  package.  (For example, in source packages, the first
>  	  paragraph refers to the source package, and later paragraphs
> -	  refer to binary packages generated from the source.)
> +	  refer to binary packages generated from the source.).  The

I can fix this when applying it, but when the entire sentence is
parenthesized, there should be only one period, placed inside the
parentheses.

>  	<p>
> -	  Many fields' values may span several lines; in this case
> -	  each continuation line must start with a space or a tab.
> -	  Any trailing spaces or tabs at the end of individual
> -	  lines of a field value are ignored. 
> +	  Fields values may be contained in a logical line that spans
> +	  several lines; these lines are called continuation lines and
> +	  must start with a space or a tab. Any trailing spaces or tabs
> +	  at the end of individual lines of a field value are ignored.
>  	</p>

How about this:

    <p>
      There are three types of fields:
      <taglist>
        <tag>simple</tag>
        <item>
          The field, including its value, must be a single line.  Folding
          of the field is not permitted.  This is the default field type
          if the definition of the field does not specify a different
          type.
        </item>
        <tag>folded</tag>
        <item>
          The value of a folded field is a logical line that may span
          several lines.  The lines after the first are called
          continuation lines and must start with a space or a tab.
          Whitespace, including any newlines, are not significant in the
          field values of folded fields.<footnote>
            This folding method is similar to RFC 5322, allowing control
            files that contain only one paragraph and no multiline fields
            to be read by parsers written for RFC 5322.
          </footnote>
        </item>
        <tag>multiline</tag>
        <item>
          The value of a multiline field may consist of multiple lines.
          The first line of the value, the part on the same line as the
          field name, often has special significance or may have to be
          empty.  Whitespace, including newlines, is significant in the
          values of multiline fields.
        </item>
      </taglist>
    </p>

>  	  <p>
> -	    The first line of the field value (the part on the same line
> -	    as <tt>Changes:</tt>) is always empty.  The content of the
> +	    The first line of this multiline field (the part on the same
> +	    line as <tt>Changes:</tt>) is always empty. The content of the

I think you still need to keep the word "value" here.

> @@ -4425,16 +4456,16 @@ Checksums-Sha256:
>  	  Whitespace may appear at any point in the version
>  	  specification subject to the rules in <ref
>  	  id="controlsyntax">, and must appear where it's necessary to
> -	  disambiguate; it is not otherwise significant.  All of the
> -	  relationship fields may span multiple lines.	For
> -	  consistency and in case of future changes to
> +	  disambiguate; it is not otherwise significant.
> +	  The relationship fields can only be folded in source package
> +	  control files For consistency and in case of future changes to

Missing end of sentence punctuation here.

Otherwise, this looks great to me.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Mon, 20 Sep 2010 07:21:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Charles Plessy <plessy@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 20 Sep 2010 07:21:05 GMT) Full text and rfc822 format available.

Message #90 received at 593909@bugs.debian.org (full text, mbox):

From: Charles Plessy <plessy@debian.org>
To: 593909@bugs.debian.org
Subject: Re: Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.
Date: Mon, 20 Sep 2010 16:15:47 +0900
[Message part 1 (text/plain, inline)]
Le Sat, Sep 18, 2010 at 09:46:41PM -0700, Russ Allbery a écrit :
> 
> How about this:
> 
>     <p>
>       There are three types of fields:
>       <taglist>
>         <tag>simple</tag>
>         <tag>folded</tag>
>         <tag>multiline</tag>

I think that it is a good idea. I took your wording, but moved what was common
between folded and multiline fields to the previous paragraph.

Here is a patch that takes this and your other comments in account. It
addresses #501930 and #593909 at the same time, but nobody objected for the
moment.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan
[0001-Clarification-of-the-format-of-control-files-Closes-.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Sat, 25 Sep 2010 04:51:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 25 Sep 2010 04:51:03 GMT) Full text and rfc822 format available.

Message #95 received at 593909@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Charles Plessy <plessy@debian.org>
Cc: 593909@bugs.debian.org
Subject: Re: Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.
Date: Fri, 24 Sep 2010 21:47:49 -0700
Charles Plessy <plessy@debian.org> writes:

> I think that it is a good idea. I took your wording, but moved what was
> common between folded and multiline fields to the previous paragraph.

That looks mostly right except I think you moved a bit too much.

> -	  Many fields' values may span several lines; in this case
> -	  each continuation line must start with a space or a tab.
> -	  Any trailing spaces or tabs at the end of individual
> -	  lines of a field value are ignored. 
> +	  According to the types defined below, fields values may be
> +	  contained in a logical line that spans several lines.  The
> +	  lines after the first are called continuation lines and
> +	  must start with a space or a tab.  Any trailing spaces or tabs
> +	  at the end of individual lines of a field value are ignored.

Multiline fields aren't a single logical line that spans several lines.
They have a value that consists of several lines, both real and logical.
Only folded fields consist of a single logical line that spans multiple
lines.

The other two sentences are fine here.

> +	    <tag>folded</tag>
> +	    <item>
> +	      The value of a folded field is a logical line that may span
> +	      several lines.  Whitespace, including any newlines, are not
> +	      significant in the field values of folded fields.<footnote>

"is not significant" (whitespace is conventionally a mass noun in
technical English).

Otherwise looks great to me.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Sat, 25 Sep 2010 06:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Charles Plessy <plessy@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 25 Sep 2010 06:39:03 GMT) Full text and rfc822 format available.

Message #100 received at 593909@bugs.debian.org (full text, mbox):

From: Charles Plessy <plessy@debian.org>
To: 593909@bugs.debian.org
Subject: Re: Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.
Date: Sat, 25 Sep 2010 15:35:18 +0900
Le Fri, Sep 24, 2010 at 09:47:49PM -0700, Russ Allbery a écrit :
> 
> That looks mostly right except I think you moved a bit too much.
> 
> > -	  Many fields' values may span several lines; in this case
> > -	  each continuation line must start with a space or a tab.
> > -	  Any trailing spaces or tabs at the end of individual
> > -	  lines of a field value are ignored. 
> > +	  According to the types defined below, fields values may be
> > +	  contained in a logical line that spans several lines.  The
> > +	  lines after the first are called continuation lines and
> > +	  must start with a space or a tab.  Any trailing spaces or tabs
> > +	  at the end of individual lines of a field value are ignored.
> 
> Multiline fields aren't a single logical line that spans several lines.
> They have a value that consists of several lines, both real and logical.
> Only folded fields consist of a single logical line that spans multiple
> lines.

Hi Russ,

I was a bit afraid of receiving this answer. Actually, I made some research
before proposing this wording, to better figure out what a “logical line” is.
Unfortunately, there is not one single defintion. In some cases like the emacs
[Visual Line mode][1], a logical line does not contain newline characters. But
in some other cases like [Python][2], it does, as in the following example
typed in the python interpreter:

>>> '''foo
... bar
... 
... baz'''
'foo\nbar\n\nbaz'
 
[1]: http://www.gnu.org/software/emacs/manual/html_node/emacs/Visual-Line-Mode.html
[2]: http://docs.python.org/reference/lexical_analysis.html#line-structure

The reason why I tried to fit the folded and multiline fields under the same
definition of a logical line is that otherwise there was no definition of how
to construct a multiline field. How about adding ‘Other lines are added
following the same syntax as the continuation lines the folded fields.’ to your
original wording:

	The value of a multiline field may consist of multiple lines.
	The first line of the value, the part on the same line as the
	field name, often has special significance or may have to be
	empty.  Other lines are added following the same syntax as the
	continuation lines the folded fields.  Whitespace, including
	newlines, is significant in the values of multiline fields. 

Have a nice week-end,

-- 
Charles




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Sat, 25 Sep 2010 06:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 25 Sep 2010 06:45:03 GMT) Full text and rfc822 format available.

Message #105 received at 593909@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Charles Plessy <plessy@debian.org>
Cc: 593909@bugs.debian.org
Subject: Re: Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.
Date: Fri, 24 Sep 2010 23:42:00 -0700
Charles Plessy <plessy@debian.org> writes:

> I was a bit afraid of receiving this answer. Actually, I made some
> research before proposing this wording, to better figure out what a
> “logical line” is.  Unfortunately, there is not one single defintion. In
> some cases like the emacs [Visual Line mode][1], a logical line does not
> contain newline characters. But in some other cases like [Python][2], it
> does, as in the following example typed in the python interpreter:

RFC 5322 section 2.2.3 is probably the relevant definition for our
purposes:

2.2.3.  Long Header Fields

   Each header field is logically a single line of characters comprising
   the field name, the colon, and the field body.  For convenience
   however, and to deal with the 998/78 character limitations per line,
   the field body portion of a header field can be split into a
   multiple-line representation; this is called "folding".  The general
   rule is that wherever this specification allows for folding white
   space (not simply WSP characters), a CRLF may be inserted before any
   WSP.

   For example, the header field:

   Subject: This is a test

   can be represented as:

   Subject: This
    is a test

      Note: Though structured field bodies are defined in such a way
      that folding can take place between many of the lexical tokens
      (and even within some of the lexical tokens), folding SHOULD be
      limited to placing the CRLF at higher-level syntactic breaks.  For
      instance, if a field body is defined as comma-separated values, it
      is recommended that folding occur after the comma separating the
      structured items in preference to other places where the field
      could be folded, even if it is allowed elsewhere.

   The process of moving from this folded multiple-line representation
   of a header field to its single line representation is called
   "unfolding".  Unfolding is accomplished by simply removing any CRLF
   that is immediately followed by WSP.  Each header field should be
   treated in its unfolded form for further syntactic and semantic
   evaluation.  An unfolded header field has no length restriction and
   therefore may be indeterminately long.

> The reason why I tried to fit the folded and multiline fields under the
> same definition of a logical line is that otherwise there was no
> definition of how to construct a multiline field. How about adding
> ‘Other lines are added following the same syntax as the continuation
> lines the folded fields.’ to your original wording:

> 	The value of a multiline field may consist of multiple lines.
> 	The first line of the value, the part on the same line as the
> 	field name, often has special significance or may have to be
> 	empty.  Other lines are added following the same syntax as the
> 	continuation lines the folded fields.  Whitespace, including
> 	newlines, is significant in the values of multiline fields. 

Yup, that sounds great.

> Have a nice week-end,

You too!

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Sat, 25 Sep 2010 07:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Charles Plessy <plessy@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 25 Sep 2010 07:24:03 GMT) Full text and rfc822 format available.

Message #110 received at 593909@bugs.debian.org (full text, mbox):

From: Charles Plessy <plessy@debian.org>
To: 593909@bugs.debian.org
Subject: Re: Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.
Date: Sat, 25 Sep 2010 16:20:17 +0900
[Message part 1 (text/plain, inline)]
Le Fri, Sep 24, 2010 at 11:42:00PM -0700, Russ Allbery a écrit :
> Charles Plessy <plessy@debian.org> writes:
> 
> > The reason why I tried to fit the folded and multiline fields under the
> > same definition of a logical line is that otherwise there was no
> > definition of how to construct a multiline field. How about adding
> > ‘Other lines are added following the same syntax as the continuation
> > lines the folded fields.’ to your original wording:
> 
> > 	The value of a multiline field may consist of multiple lines.
> > 	The first line of the value, the part on the same line as the
> > 	field name, often has special significance or may have to be
> > 	empty.  Other lines are added following the same syntax as the
> > 	continuation lines the folded fields.  Whitespace, including
> > 	newlines, is significant in the values of multiline fields. 
> 
> Yup, that sounds great.


While making one more proofreading, I realised that there was another paragraph
concerned by the logical line ambiguity. Here is the change that I propose,
which is already applied in the attached patch.

          Each paragraph consists of a series of data fields; each
          field consists of the field name, followed by a colon and
          then the data/value associated with that field.  It ends at
-         the end of a logical line (see below).  Horizontal whitespace
+         the end of the line or at the end of the last
+         continuation line (see below).  Horizontal whitespace
          (spaces and tabs) may occur immediately before or after the
          value and is ignored there; it is conventional to put a
          single space after the colon.  For example, a field might

Cheers,

-- 
Charles
[0001-Clarification-of-the-format-of-control-files-Closes-.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Sun, 26 Sep 2010 15:09:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to Charles Plessy <plessy@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 26 Sep 2010 15:09:10 GMT) Full text and rfc822 format available.

Message #115 received at 593909@bugs.debian.org (full text, mbox):

From: Charles Plessy <plessy@debian.org>
To: 593909@bugs.debian.org
Cc: Jonathan Yu <jawnsy@cpan.org>, debian-dpkg@lists.debian.org
Subject: Re: Names of Fields in Control Files
Date: Mon, 27 Sep 2010 00:07:35 +0900
Le Sun, Sep 26, 2010 at 01:35:00AM -0700, Russ Allbery a écrit :
> Raphael Hertzog <hertzog@debian.org> writes:
> 
> > I'm certainly OK with policy requiring field names to be ASCII.
> 
> I think that's probably the right thing to do.

Dear all,

how about simply paraphrasing the RFC 822/5832, which our the source of
inspiration ? In that case, the requirement for field names will be to be
printable ASCII characters, except colons.

I propose the following change in the context the patch that I am preparing for
clarifying the Policy's chapter about control files, in bug #593909.

diff --git a/policy.sgml b/policy.sgml
index be0a505..5c72355 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -2493,9 +2493,11 @@ endif
        <p>
          Each paragraph consists of a series of data fields; each
          field consists of the field name, followed by a colon and
-         then the data/value associated with that field.  It ends at
-         the end of the line or at the end of the last
-         continuation line (see below).  Horizontal whitespace
+         then the data/value associated with that field.  The field
+         name is composed of printable US-ASCII characters (i.e.,
+         characters that have values between 33 and 126, inclusive),
+         except colon.  The field ends at the end of the line or at
+         the end of the last continuation line (see below).  Horizontal whitespace
          (spaces and tabs) may occur immediately before or after the
          value and is ignored there; it is conventional to put a
          single space after the colon.  For example, a field might


Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Mon, 11 Oct 2010 22:12:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 11 Oct 2010 22:12:05 GMT) Full text and rfc822 format available.

Message #120 received at 593909@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Charles Plessy <plessy@debian.org>
Cc: 593909@bugs.debian.org, Jonathan Yu <jawnsy@cpan.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#593909: Names of Fields in Control Files
Date: Mon, 11 Oct 2010 15:11:18 -0700
Charles Plessy <plessy@debian.org> writes:

> how about simply paraphrasing the RFC 822/5832, which our the source of
> inspiration ? In that case, the requirement for field names will be to
> be printable ASCII characters, except colons.

> I propose the following change in the context the patch that I am
> preparing for clarifying the Policy's chapter about control files, in
> bug #593909.

> diff --git a/policy.sgml b/policy.sgml
> index be0a505..5c72355 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -2493,9 +2493,11 @@ endif
>         <p>
>           Each paragraph consists of a series of data fields; each
>           field consists of the field name, followed by a colon and
> -         then the data/value associated with that field.  It ends at
> -         the end of the line or at the end of the last
> -         continuation line (see below).  Horizontal whitespace
> +         then the data/value associated with that field.  The field
> +         name is composed of printable US-ASCII characters (i.e.,
> +         characters that have values between 33 and 126, inclusive),
> +         except colon.  The field ends at the end of the line or at
> +         the end of the last continuation line (see below).  Horizontal whitespace
>           (spaces and tabs) may occur immediately before or after the
>           value and is ignored there; it is conventional to put a
>           single space after the colon.  For example, a field might

Seconded.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Mon, 11 Oct 2010 22:15:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 11 Oct 2010 22:15:02 GMT) Full text and rfc822 format available.

Message #125 received at 593909@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Charles Plessy <plessy@debian.org>
Cc: 593909@bugs.debian.org, Jonathan Yu <jawnsy@cpan.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#593909: Names of Fields in Control Files
Date: Mon, 11 Oct 2010 15:13:43 -0700
Charles Plessy <plessy@debian.org> writes:

> how about simply paraphrasing the RFC 822/5832, which our the source of
> inspiration ? In that case, the requirement for field names will be to
> be printable ASCII characters, except colons.

> I propose the following change in the context the patch that I am
> preparing for clarifying the Policy's chapter about control files, in
> bug #593909.

It occurred to me, on reviewing your other patch as well, that this change
should probably also say explicitly that field names may not begin with #.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Mon, 11 Oct 2010 22:18:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 11 Oct 2010 22:18:03 GMT) Full text and rfc822 format available.

Message #130 received at 593909@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Charles Plessy <plessy@debian.org>
Cc: 593909@bugs.debian.org
Subject: Re: Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.
Date: Mon, 11 Oct 2010 15:15:30 -0700
Charles Plessy <plessy@debian.org> writes:

> From: Charles Plessy <plessy@debian.org>
> Date: Sat, 25 Sep 2010 16:15:05 +0900
> Subject: [PATCH] Clarification of the format of control files, Closes: #501930, #593909.
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit

>  - Distinguishes simple, folded and mulitiline fields;
>  - Clarifies paragraph separators (#501930);
>  - The order of paragraphs is significant;
>  - Fields can have different types or purposes in different control files;
>  - Moved the description of comments from §5.2 to §5.1;
>  - Documented that relationship fields can only be folded in debian/control.
> ---
>  policy.sgml |  111 +++++++++++++++++++++++++++++++++++++----------------------
>  1 files changed, 70 insertions(+), 41 deletions(-)

[...]

This looks great to me.  Seconded.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Tue, 12 Oct 2010 15:21:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Charles Plessy <plessy@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Tue, 12 Oct 2010 15:21:02 GMT) Full text and rfc822 format available.

Message #135 received at 593909@bugs.debian.org (full text, mbox):

From: Charles Plessy <plessy@debian.org>
To: 593909@bugs.debian.org
Cc: Jonathan Yu <jawnsy@cpan.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#593909: Names of Fields in Control Files
Date: Wed, 13 Oct 2010 00:18:49 +0900
[Message part 1 (text/plain, inline)]
Le Mon, Oct 11, 2010 at 03:13:43PM -0700, Russ Allbery a écrit :
> Charles Plessy <plessy@debian.org> writes:
> 
> > how about simply paraphrasing the RFC 822/5832, which our the source of
> > inspiration ? In that case, the requirement for field names will be to
> > be printable ASCII characters, except colons.
> 
> > I propose the following change in the context the patch that I am
> > preparing for clarifying the Policy's chapter about control files, in
> > bug #593909.
> 
> It occurred to me, on reviewing your other patch as well, that this change
> should probably also say explicitly that field names may not begin with #.

Here is an updated patch, that contains the following:

          Each paragraph consists of a series of data fields; each
          field consists of the field name, followed by a colon and
-         then the data/value associated with that field.  It ends at
-         the end of the (logical) line.  Horizontal whitespace
+         then the data/value associated with that field.  The field
+         name is composed of printable ASCII characters (i.e.,
+         characters that have values between 33 and 126, inclusive)
+         except colon and must not with a begin with #.  The
+         field ends at the end of the line or at the end of the
+         last continuation line (see below).  Horizontal whitespace
          (spaces and tabs) may occur immediately before or after the
          value and is ignored there; it is conventional to put a

Apart from adding that fields names may not begin with #, I also changed
‘US-ASCII’ for ‘ASCII’, since this is the vocabulary used by the Policy.

Have a nice day,

-- 
Charles
[0001-Clarification-of-the-format-of-control-files-Closes-.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Tue, 12 Oct 2010 16:09:11 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Tue, 12 Oct 2010 16:09:11 GMT) Full text and rfc822 format available.

Message #140 received at 593909@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Charles Plessy <plessy@debian.org>
Cc: 593909@bugs.debian.org, Jonathan Yu <jawnsy@cpan.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#593909: Names of Fields in Control Files
Date: Tue, 12 Oct 2010 09:04:35 -0700
Charles Plessy <plessy@debian.org> writes:

> Here is an updated patch, that contains the following:

>           Each paragraph consists of a series of data fields; each
>           field consists of the field name, followed by a colon and
> -         then the data/value associated with that field.  It ends at
> -         the end of the (logical) line.  Horizontal whitespace
> +         then the data/value associated with that field.  The field
> +         name is composed of printable ASCII characters (i.e.,
> +         characters that have values between 33 and 126, inclusive)
> +         except colon and must not with a begin with #.  The
> +         field ends at the end of the line or at the end of the
> +         last continuation line (see below).  Horizontal whitespace
>           (spaces and tabs) may occur immediately before or after the
>           value and is ignored there; it is conventional to put a

> Apart from adding that fields names may not begin with #, I also changed
> ‘US-ASCII’ for ‘ASCII’, since this is the vocabulary used by the Policy.

And, for the record, seconding this combined patch.  Thank you for all
your work on this!

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Tue, 12 Oct 2010 16:27:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Julien Cristau <jcristau@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Tue, 12 Oct 2010 16:27:06 GMT) Full text and rfc822 format available.

Message #145 received at 593909@bugs.debian.org (full text, mbox):

From: Julien Cristau <jcristau@debian.org>
To: Charles Plessy <plessy@debian.org>, 593909@bugs.debian.org
Cc: Jonathan Yu <jawnsy@cpan.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#593909: Names of Fields in Control Files
Date: Tue, 12 Oct 2010 18:23:34 +0200
[Message part 1 (text/plain, inline)]
On Wed, Oct 13, 2010 at 00:18:49 +0900, Charles Plessy wrote:

> From: Charles Plessy <plessy@debian.org>
> Date: Wed, 13 Oct 2010 00:14:42 +0900
> Subject: [PATCH] Clarification of the format of control files, Closes: #501930, #593909.
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
>  - Specifies field names similarly to RFC 822/5832;
>  - Distinguishes simple, folded and mulitiline fields;
>  - Clarifies paragraph separators (#501930);
>  - The order of paragraphs is significant;
>  - Fields can have different types or purposes in different control files;
>  - Moved the description of comments from §5.2 to §5.1;
>  - Documented that relationship fields can only be folded in debian/control.

Seconded.

Cheers,
Julien
[signature.asc (application/pgp-signature, inline)]

Forcibly Merged 593909 618013. Request was from Charles Plessy <plessy@debian.org> to control@bugs.debian.org. (Sun, 20 Mar 2011 06:57:08 GMT) Full text and rfc822 format available.

Changed Bug title to 'clarify where multi-line fields are allowed in control files' from 'debian-policy: Clarifications about the syntax of Debian control files.' Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Mon, 04 Apr 2011 03:27:10 GMT) Full text and rfc822 format available.

Changed Bug title to 'clarify the syntax of Debian control files' from 'clarify where multi-line fields are allowed in control files' Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Mon, 04 Apr 2011 03:27:11 GMT) Full text and rfc822 format available.

Added tag(s) patch. Request was from Charles Plessy <plessy@debian.org> to control@bugs.debian.org. (Mon, 04 Apr 2011 13:48:06 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#593909; Package debian-policy. (Wed, 06 Apr 2011 07:36:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Wed, 06 Apr 2011 07:36:05 GMT) Full text and rfc822 format available.

Message #158 received at 593909@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Charles Plessy <plessy@debian.org>
Cc: 593909@bugs.debian.org, Jonathan Yu <jawnsy@cpan.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#593909: Names of Fields in Control Files
Date: Wed, 06 Apr 2011 00:25:45 -0700
Charles Plessy <plessy@debian.org> writes:

> Here is an updated patch, that contains the following:

>           Each paragraph consists of a series of data fields; each
>           field consists of the field name, followed by a colon and
> -         then the data/value associated with that field.  It ends at
> -         the end of the (logical) line.  Horizontal whitespace
> +         then the data/value associated with that field.  The field
> +         name is composed of printable ASCII characters (i.e.,
> +         characters that have values between 33 and 126, inclusive)
> +         except colon and must not with a begin with #.  The
> +         field ends at the end of the line or at the end of the
> +         last continuation line (see below).  Horizontal whitespace
>           (spaces and tabs) may occur immediately before or after the
>           value and is ignored there; it is conventional to put a

> Apart from adding that fields names may not begin with #, I also changed
> ‘US-ASCII’ for ‘ASCII’, since this is the vocabulary used by the Policy.

Thanks, this is now applied for the next Policy release.  Sorry about the
long delay.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Added tag(s) pending; removed tag(s) patch. Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Wed, 06 Apr 2011 07:37:18 GMT) Full text and rfc822 format available.

Reply sent to Russ Allbery <rra@debian.org>:
You have taken responsibility. (Thu, 07 Apr 2011 06:15:58 GMT) Full text and rfc822 format available.

Notification sent to Charles Plessy <plessy@debian.org>:
Bug acknowledged by developer. (Thu, 07 Apr 2011 06:16:07 GMT) Full text and rfc822 format available.

Message #165 received at 593909-close@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 593909-close@bugs.debian.org
Subject: Bug#593909: fixed in debian-policy 3.9.2.0
Date: Thu, 07 Apr 2011 06:02:15 +0000
Source: debian-policy
Source-Version: 3.9.2.0

We believe that the bug you reported is fixed in the latest version of
debian-policy, which is due to be installed in the Debian FTP archive:

debian-policy_3.9.2.0.dsc
  to main/d/debian-policy/debian-policy_3.9.2.0.dsc
debian-policy_3.9.2.0.tar.gz
  to main/d/debian-policy/debian-policy_3.9.2.0.tar.gz
debian-policy_3.9.2.0_all.deb
  to main/d/debian-policy/debian-policy_3.9.2.0_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 593909@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Russ Allbery <rra@debian.org> (supplier of updated debian-policy package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Wed, 06 Apr 2011 22:48:55 -0700
Source: debian-policy
Binary: debian-policy
Architecture: source all
Version: 3.9.2.0
Distribution: unstable
Urgency: low
Maintainer: Debian Policy List <debian-policy@lists.debian.org>
Changed-By: Russ Allbery <rra@debian.org>
Description: 
 debian-policy - Debian Policy Manual and related documents
Closes: 459868 488214 501930 504880 536790 581011 588014 590696 591857 593909 594274 594542 594656 594658 597074 599944 606869 609160 619186
Changes: 
 debian-policy (3.9.2.0) unstable; urgency=low
 .
   * Policy: Require human Maintainer or Uploader, clarify Maintainer
     Wording: Russ Allbery <rra@debian.org>
     Seconded: Charles Plessy <plessy@debian.org>
     Seconded: Raphaël Hertzog <hertzog@debian.org>
     Closes: #459868, #581011
   * Policy: Add an FHS exception on GNU/Hurd for /hurd and /servers
     Wording: Russ Allbery <rra@debian.org>
     Seconded: Andrew McMillan <andrew@morphoss.com>
     Seconded: Guillem Jover <guillem@debian.org>
     Closes: #594658
   * Policy: Document DM-Upload-Allowed
     Wording: Charles Plessy <plessy@debian.org>
     Seconded: Andrew McMillan <andrew@morphoss.com>
     Seconded: Russ Allbery <rra@debian.org>
     Closes: #588014
   * Policy: Update multiarch FHS exception for i386 naming
     Wording: Steve Langasek <vorlon@debian.org>
     Seconded: Aurelien Jarno <aurelien@aurel32.net>
     Seconded: Raphael Hertzog <hertzog@debian.org>
     Closes: #619186
   * Policy: Significant additions to maintainer script documentation
     Wording: Russ Allbery <rra@debian.org>
     Seconded: Steve Langasek <vorlon@debian.org>
     Seconded: Raphaël Hertzog <hertzog@debian.org>
     Closes: #504880
   * Policy: Clarify format of Debian control fields
     Wording: Charles Plessy <plessy@debian.org>
     Seconded: Russ Allbery <rra@debian.org>
     Seconded: Julien Cristau <jcristau@debian.org>
     Closes: #501930, #593909
   * Virtual: Added mailx as a new virtual package
     Wording: Russ Allbery <rra@debian.org>
     Seconded: Raphaël Hertzog <hertzog@debian.org>
     Seconded: Giacomo A. Catenazzi <cate@debian.org>
     Closes: #488214
   * Be more verbose in defining the build architecture and the host
     architecture and consistently refer to architecture rather than
     machine.  (Closes: #591857)
   * Correct the name of the Filesystem Hierarchy Standard in the package
     description.  Patch from Christoph Anton Mitterer.  (Closes: #590696)
   * Use the word "implemented" to describe required targets in
     debian/rules, which is clearer about allowing wildcard rules.  List
     the required rules in their own paragraph rather than with the
     paragraph discussing non-interactivity, and explicitly mark all rules
     as either required or optional.  (Closes: #536790)
   * Update the ldconfig footnote listing the /etc/ld.so.conf directories
     to remove the libc5 compatibility directories and mention the
     multiarch triplet directories.  Based on a patch by Charles Plessy.
     (Closes: #597074)
   * Add introductory paragraphs for each archive area explaining briefly
     the purpose of that archive area.  Based on a proposal by CJ
     Fearnley.  (Closes: #594542)
   * Change all non-historical references to Debian GNU/Linux to simply
     Debian since Debian now includes FreeBSD-based architectures.  Patch
     from Guillem Jover.  (Closes: #594656)
   * Remove references to the obsolete debmake package.
   * Update the list of Policy maintainers.
   * Wrap Uploaders in debian/control.
   * Move Build-Depends-Indep to Build-Depends (there's no reason to use
     -Indep in a package that builds only architecture-independent binary
     packages), wrap it, and remove version restrictions that are older
     than the version in oldstable.
   * Add emacs23 to the build dependencies and remove the files generated
     from org source from the revision control repository.  Build and clean
     files from org source unconditionally.  Add Process.{txt,html} to the
     list of files generated from org source.  (Closes: #594274)
   * Fix URLs under www.freedesktop.org to avoid permanent redirects.
     Thanks, David Prévot.  (Closes: #606869)
   * Add a cross-reference to the Pre-Depends requirement in 3.5 to section
     7.2 where Pre-Depends is defined.  Thanks, Mattias Ellert and Jonathan
     Nieder.  (Closes: #599944)
   * Include the new (optional) copyright format that was drafted as DEP-5.
     This is not yet a final version; that's expected to come in the
     3.9.3.0 release.  Thanks to all the DEP-5 contributors and to Lars
     Wirzenius and Charles Plessy for the integration into the Policy
     package.  (Closes: #609160)
Checksums-Sha1: 
 3fbe1185dd3abd9f553cefbc2e8b353864bdd99b 1471 debian-policy_3.9.2.0.dsc
 f8b59ed7adcaec2dd78b77010eba9f9934e13012 693834 debian-policy_3.9.2.0.tar.gz
 3854a70a825272ff6a1e1473eb90369f5c1c6c68 1907938 debian-policy_3.9.2.0_all.deb
Checksums-Sha256: 
 231893c0f9dd4d8bd20aa5d53e871423c15ce0eb48ebc53652316a0e7eca8f89 1471 debian-policy_3.9.2.0.dsc
 8be1c13c6b05b167b356f505cab74f3e6a84be096215e64ad741d672b6f943a6 693834 debian-policy_3.9.2.0.tar.gz
 1a587553e9fc5ad93f3ddf8d752131efc737dff7810a6c170fe67cbb8a642eb5 1907938 debian-policy_3.9.2.0_all.deb
Files: 
 cad30289440ae005513484e7af83039f 1471 doc optional debian-policy_3.9.2.0.dsc
 b90105f64bcaedd3b1c182689ac9c6c8 693834 doc optional debian-policy_3.9.2.0.tar.gz
 73bef9fc65be0091233daa701e494104 1907938 doc optional debian-policy_3.9.2.0_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJNnVKxAAoJEH2AMVxXNt51S1kH/19xBm48ZzXnn2tSEHaCWKIz
sh86ppJArmwvxUu0BzwlSg2jr01M3pyynwVzgevGAQ9QlK2bD1MODlq5zQ23JLk8
ZHthYq/f15BkWuwMPVfnWeUtLVe4Xo6LL/LJGMjYiWTGxyv8OtctDVYz0olksmjr
gNp4rTUIzRfL8ucN3ypq0Xct7K2QilXQFdtEpHSRdsSPLC42cQgH/0wqo1PzMT7w
micFsqgGT5ZDUq+y4eNE6AzAZynVJgUAgnG0BMANucFJ8pVnVPmUB8rAEaURPGib
rjwuIHftPliJyI0hoBzWV1AU9t/I7IPekCJx+eqhVnUMF+sQexwHssEWmAZbtwY=
=o5f6
-----END PGP SIGNATURE-----





Reply sent to Russ Allbery <rra@debian.org>:
You have taken responsibility. (Thu, 07 Apr 2011 06:16:15 GMT) Full text and rfc822 format available.

Notification sent to Ansgar Burchardt <ansgar@2008.43-1.org>:
Bug acknowledged by developer. (Thu, 07 Apr 2011 06:16:25 GMT) Full text and rfc822 format available.

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sun, 15 May 2011 07:32:36 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sun Apr 20 13:44:31 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.