On su, 2010-08-22 at 16:12 +0900, Charles Plessy wrote: > I also feel a contradiction to call ‘free-form’ some text that is formatted > according to some markup rules, even if they are simple. I propose to replace > instances like: > > Free-form text formatted like package long descriptions > > by: > > Formatted text like package long descriptions
ACK, done. > All in all, I would recommend to make these fields free-form. Packaging teams > that would like to use a more specialised syntax can add their own local > policies on top of the DEP. I disagree with this: I think a line-based list is perfectly fine for Upstream-Contact. Does anyone else have an opinion? > > @@ -99,13 +132,15 @@ > > * **`Source`** > > * Optional > > * Single occurrence > > + * Value: single line > > * Syntax: One or more URIs, one per line, indicating the primary > > point of distribution of the software. > > Since the syntax allows multiple URIs, and since the URIs may be long, I think > that allowing newlines in the field will make it more readable. for instance > by > making it free-form (not formatted, see below). Actually, I think I made a mistake: I think Source should be a line-based list. This will make it easier for parsers to extract the URIs. Splitting a URI to two physical lines seems to me a bad idea, and messes up URI parsing in too many contexts. (The real fix is to get upstream to not have excessively long URIs, but that's hard to fix.) > If the extended description finally requires double space for verbatim > display, > then how abould calling the ‘special first line’ synopsis, to be closer to the > vocabulary used in the specification of the Description field ? Could some English experts weigh in whether the word synopsis is a good way to describe the list of license short names? -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/1282514846.12989.396.ca...@havelock
