Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.
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
Reply to: