Re: Bug#494714: dpkg-dev - dpkg-genchanges should fold lines
On Sat, 2009-05-16 at 02:10 -0500, Manoj Srivastava wrote:
>
> It is my recollection that each field in the control file (and
> perhaps others) was supposed to follow rfc822 (now rfc5322), and that
> says:
> ,----
> | 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.
> |
> | 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.
> `----
>
> So, each field is always one logical line, but may consist of
> multiple physical lines.
>
> I suggest we add explanation like this to the policy document.
It seems reasonable that we should follow this manner of specification,
but will this introduce any issues for fields which are currently
defined as multiple lines?
If we applied this unfolding to the description, for example, we would
lose the line break information, so I suspect we can't just pile
straightforwardly onto this bandwagon, but would need to make it
explicit that some fields cannot be unfolded in this manner.
Cheers,
Andrew.
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Be careful! Is it classified?
------------------------------------------------------------------------
Reply to: