On Sun, Jan 23, 2011 at 03:09:00PM +0100, Dominique Dumont wrote: > Le vendredi 21 janvier 2011 22:18:18, Steve Langasek a écrit : > > Not having looked at the code, I'm wondering: do you apply these > > translations to all files regardless of the Format/Format-Specification > > field's value, or are you selective about only applying these upgrades to > > fields that were considered valid at the time? > It's not selective. The model [1] that defines the behavior during the upgrade > is purely declarative. > Config::Model was designed to handle configuration files where the concept of > unknown parameter does not apply. > > I don't think, for > > instance, that a file that has a declaration of Format: > > http://dep.debian.net/deps/dep5/ [1] should have 'Maintainer' fields > > auto-upgraded to 'Upstream-Contact', but that this should instead be > > treated as an unknown field. > Like others, the history of this parameter is complicated. It was required, > then deprecated, and now legal (but with a possibly different semantic > content). If you factor in the possibility of human error (e.g. modern > format, but forgotten Maintainer field), having a DEP-5 validated file > may not mean much. I don't think it means much when applying such heuristics to auto-convert field names, either. I have always been lukewarm on the idea of specifying within the DEP itself that "extra fields can be added" without standards-compliance implications. I don't think people should be adding random fields here without first *defining* those fields; and with DEP5, defining them is as straightforward as taking a copy of the DEP, adding your field definitions to it, posting that modified document to the web and referencing the new URL in your Format: declaration. It's not like this even requires you to write a formal XML DTD or something, so I really don't think this is too high a barrier; and if someone thinks that it is, there's always the Comment: field already defined for the purpose of including arbitrary text in the document. It would be my strong preference to see the language in DEP5 clarified in this manner, and parsers modified to treat unknown fields as validation *failures* when referencing a known Format: URL. > For instance, this DEP-5 file is valid, since Maintainer field > is accepted as an unknown parameter and Upstream-Contact is optional: > Format: http://dep.debian.net/deps/dep5/ > Maintainer: foo@bar > Files: * > Copyright: (c) me > License: GPL-2+ > This program is free software; you can redistribute it > and/or modify it [snip] > In this case, is this an error or a DD who does not > like the Upstream-Contact keyword ? Yes, I think that's a good example of why the current DEP language needs to be improved on this score. Thanks, -- 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
Attachment:
signature.asc
Description: Digital signature