Re: RFC round 3: DEP-3: Patch Tagging Guidelines
Thank you for the feedback. It made me understood that the format can be even
simplified. First of all, let me clarify that I do not aim at describing the
format of Debian control files, but the proposed format for DEP5, which I
propose for DEP3 as well since it is simple and does not require prior
experience of Debian control files.
In the informal discussions about DEP5, a popular request was to be allowed to
use free-form plain comments. I think that I read such a request in the DEP3
discussion as well. With this goal in mind, I propose that anything that is not
in a field is a comment. Then there is no need to define embedded comments, and
the empty lines above the first field can be ignored as comments and do not
need to be specified. The only drawback is that a comment must not contain
lines that look like starting a new field. In my experience with
debian/copyright files, this is not a problem.
If everything that is not a field is a comment, then there is no need to
specify a signal for end of header (lines with spaces only), and if lines with
spaces only are allowed, then there is no need anymore for escaping empty lines
in field bodies with dot characters, which prettifies the field bodies and
simplifies the format. In the case of DEP3, spurious fields could appear if the
patch itself is parsed. Nevertheless, this can be solved by specifying that the
patch header is extracted by the parser in a way that depends on the format of
the patch, and that only the extracted patch header is fully compliant with the
pseudo RFC-822 format described below. This also has the advantage of moving
out the dpatch-specific contorsions from the definition of the format.
This would give:
Fields are logical elements composed of a field name, followed by a colon,
followed by a field body, and terminated by a line feed character.
- A field name is composed of printable characters, except colons.
- The field body is composed of any character. Leading spaces of the body are
ignored. To avoid problems with multi-line values, any line feed character
must be escaped by following it by a space. The line that contains that space
is called a continuation line.
- Lines that are not continuation lines and do not start a new field are plain
Have a nice day,
Tsurumi, Kanagawa, Japan