Re: New version of DEP-5 parser
Le dimanche 23 janvier 2011 15:26:46, Jonas Smedegaard a écrit : 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 ? How about emit a warning in unknown-but-likely-error cases like this. ...and perhaps optionally be invasive as is now the default. Err, correct me if I'm wrong, but that's already the case whether you run with -save option or not. E.g. on the example above, you can have the warnings without modifying copyright file: $ cp debian/copyright debian/copyright.bak $ config-edit -appli dpkg-copyright -ui none Element 'Maintainer' of node 'Debian::Dpkg::Copyright' is deprecated $ diff debian/copyright debian/copyright.bak And you can have the invasive behavior with the -save option $ config-edit -appli dpkg-copyright -ui none -save Element 'Maintainer' of node 'Debian::Dpkg::Copyright' is deprecated $ diff debian/copyright debian/copyright.bak 2,3c2,3 Upstream-Contact: foo@bar Source: --- Maintainer: foo@bar Is this the behavior you're thinking of ? All the best [ note to self: fix fishy behavior with the empty Source line ] Dominique PS: Note to all: I'm slowing down on DEP-5 parser development because I'm busy preparing FOSDEM -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101261120.38707.domi.dum...@free.fr
Re: DEP5: extra fields compliant with the spec? [Was, Re: New version of DEP-5 parser]
On su, 2011-01-23 at 12:29 -0800, Steve Langasek wrote: 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. Would you like to propose a patch for discussion? My personal preference, at this time, would be to not change DEP5 about this, but re-visit it later if this turns out to be a problem. If the consensus on -project is that changing the spec now is better, however, then let's do that. (I see my current role as DEP5 driver to stand on the brake so we make only those changes that are really seemed necessary, so we can get this thing out of the door eventually. I'm not opposed to further changes, but I would like to avoid re-visiting things unless there's a strong need. I keep noticing things I'd like to do entirely differently, but stopping myself from suggesting them.) -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1295975424.4771.52.ca...@havelock.lan
Re: New version of DEP-5 parser
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. 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 ? Note that the debian policy is respected since the upstream info is provided. But the original objective of DEP5 (facilitate automated checking and reporting of licenses for packages and sets of packages) is in jeopardy. If the consensus is that such a Maintainer field should be left as is, one solution would be to keep the current model with its upgrade capability and provide another pure dep-5 model. Then the user would to choose between: - the dep-5-model-with-upgrade (and a few drawbacks like deprecated Maintainer fields) - a pure dep-5 without migration I'll provide the latter if people ask for it for actual use. All the best Dominique [1] http://cpansearch.perl.org/src/DDUMONT/Config-Model-1.230/lib/Config/Model/models/Debian/Dpkg/Copyright.pl -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101231509.01093.domi.dum...@free.fr
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 : 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. 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 ? How about emit a warning in unknown-but-likely-error cases like this. ...and perhaps _optionally_ be invasive as is now the default. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
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. 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: DEP5: extra fields compliant with the spec? [Was, Re: New version of DEP-5 parser]
On Sun, Jan 23, 2011 at 12:29:03PM -0800, Steve Langasek wrote: 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. +1 - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
New version of DEP-5 parser
Hello I've fixed upstream [1] most (hopefully all) the issues regarding the DEP5 parser based on Config::Model that were mentioned on these lists or in the BTS. The new version is already (thanks gregoa) available on Debian/Sid in libconfig-model-perl 1.230 I've updated the parser so as to upgrade older version of copyright file (even pre DEP-5 versions) into the current format. All old keywords are translated into new keywords (except the old keywords I do not know yet about :-p ) For those who missed the previous thread, you can find more details in my blog [2]. Last but not least, I'll present Config::Model and its applications (including OpenSsh config and DEP-5 copyright) in the cross-distro dev room at FOSDEM in 2 weeks. Feel free to come by and let's discuss DEP5 or other possible applications. All the best Dominique [1] http://search.cpan.org/dist/Config-Model/ [2] http://ddumont.wordpress.com/2011/01/13/debian-copyright-dep5-parsereditorvalidatormigrator-is- released/ -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101212116.59690.domi.dum...@free.fr
Re: New version of DEP-5 parser
Hi Dominique, On Fri, Jan 21, 2011 at 09:16:59PM +0100, Dominique Dumont wrote: I've fixed upstream [1] most (hopefully all) the issues regarding the DEP5 parser based on Config::Model that were mentioned on these lists or in the BTS. The new version is already (thanks gregoa) available on Debian/Sid in libconfig-model-perl 1.230 I've updated the parser so as to upgrade older version of copyright file (even pre DEP-5 versions) into the current format. All old keywords are translated into new keywords (except the old keywords I do not know yet about :-p ) 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? 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. -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org [1] much as I disagree that an unversioned URL should be used at all here signature.asc Description: Digital signature
