On Mon, Dec 19, 2011 at 10:12:52AM +0100, Charles Plessy wrote: > > I don't think that should be legal either however; we allow "extra > > fields" to be added to any paragraph, but I don't believe the intent is > > to allow *defined* fields to be used in paragraphs where they are not > > specified to be permitted - only to allow new field names to be used. > > So I think something like the attached patch should be applied. > > Thoughts? > I am sometimes using an extra Source field in some Files paragraphs, when > they define works that are not the creation of the main authors, > especially when it was difficult to find their original upstream location. Why use the same field name (Source) in the Files paragraphs as in the header paragraph when this is not defined - instead of using, say, 'Component-Source' (or even just 'Comment')? Have you proposed making this use of Source part of the standard? If so I'm afraid I missed that. I can understand that you would want to document the source of individual components in cases where the whole work is no longer available, but I think that reusing an already-defined field name for the purpose just makes it harder for validators to distinguish between accidental errors and deliberate extensions. Indeed, there is already one recommendation in the spec for exactly this purpose: No prefixing is necessary or desired, but please avoid names similar to standard ones so that mistakes are easier to catch. There's nothing more similar to a standard field name than one which is identical. ;) > Of course, I agree that making a stand-alone License paragraph with an > extra Fiels field would be an horror. But I am inclined to think that it > is obvious enough that we do not need to constrain the syntax. With the > change you propose extra checks are needed while parsing. > If nevertheless the consensus is to apply your changes, I would like to > suggest to normalise the vocabulary: either “extra fields” or “additional > fields”, but the current patch uses both. The Policy's chapter 5 uses > “additional”, so this is where my choice would go even if it will increase > the difficulty to search for previous discussions on the topic. That's fair. Updated patch attached. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
=== modified file 'dep5/copyright-format.xml'
--- old/dep5/copyright-format.xml 2011-12-18 17:38:43 +0000
+++ new/dep5/copyright-format.xml 2011-12-19 18:23:14 +0000
@@ -108,14 +108,17 @@
mandated upstream information, copyright notices and licensing details.
</para>
<para>
- The syntax of the file is the same as for other Debian control files, as
- specified in the Debian Policy Manual. See its <ulink
+ The syntax of the file is the same as for other Debian control files,
+ as specified in the Debian Policy Manual. See its <ulink
url="http://www.debian.org/doc/debian-policy/ch-controlfields#s-controlsyntax";>section
- 5.1</ulink> for details. Extra fields can be added to any paragraph. No
- prefixing is necessary or desired, but please avoid names similar to
- standard ones so that mistakes are easier to catch. Future versions of
- the <filename>debian/copyright</filename> specification will attempt to
- avoid conflicting specifications for widely used extra fields.
+ 5.1</ulink> for details. Additional fields can be added to any
+ paragraph, but the fields defined in this document are only allowed in
+ the paragraphs where they are specified to be present. No prefixing
+ is necessary or desired for new field names, but please avoid names
+ similar to standard ones so that mistakes are easier to catch. Future
+ versions of the <filename>debian/copyright</filename> specification
+ will attempt to avoid conflicting specifications for widely-used
+ additional fields.
</para>
<para>
The file consists of two or more paragraphs. At minimum, the file
Attachment:
signature.asc
Description: Digital signature