[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

DEP5: "extra" fields compliant with the spec? [Was, Re: New version of DEP-5 parser]

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.

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

Reply to: