Bug#593909: Names of Fields in Control Files

[Russ Allbery]

Charles Plessy  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 (r...@debian.org)   



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#593909: Names of Fields in Control Files

[Julien Cristau]

On Wed, Oct 13, 2010 at 00:18:49 +0900, Charles Plessy wrote:

> From: Charles Plessy 
> 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
Description: Digital signature

Bug#593909: Names of Fields in Control Files

[Russ Allbery]

Charles Plessy  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 (r...@debian.org)   



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#593909: Names of Fields in Control Files

[Charles Plessy]

Le Mon, Oct 11, 2010 at 03:13:43PM -0700, Russ Allbery a écrit :
> Charles Plessy  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
>From ae5afd407773a02863169dc71bdaacaeb644570c Mon Sep 17 00:00:00 2001
From: Charles Plessy 
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.
---
 policy.sgml |  116 +-
 1 files changed, 74 insertions(+), 42 deletions(-)

diff --git a/policy.sgml b/policy.sgml
index 642f672..02637f0 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -2479,19 +2479,26 @@ endif
 	  fields
 		The paragraphs are also sometimes referred to as stanzas.
 	  .
-	  The paragraphs are separated by blank lines.  Some control
+	  The paragraphs are separated by empty lines.  Parsers may accept
+	  lines consisting solely of spaces and tabs as paragraph
+	  separators, but control files should use empty lines.  Some control
 	  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
+	  ordering of the paragraphs in control files is significant.
 	
 
 	
 	  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
 	  single space after the colon.  For example, a field might
@@ -2509,22 +2516,52 @@ Package: libc6
 	
 
 	
-	  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. 
+	  There are three types of fields:
+	  
+	simple
+	
+	  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.
+	
+	folded
+	
+	  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.
+	  Whites

Bug#593909: Names of Fields in Control Files

[Russ Allbery]

Charles Plessy  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 (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#593909: Names of Fields in Control Files

[Russ Allbery]

Charles Plessy  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
> 
>   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 (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#593909: Names of Fields in Control Files

[Charles Plessy]

Le Sun, Sep 26, 2010 at 01:35:00AM -0700, Russ Allbery a écrit :
> Raphael Hertzog  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

  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



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org