Re: New version of DEP-5 parser
Le mardi 22 février 2011 20:24:02, Dominique Dumont a écrit : Le mardi 22 février 2011 19:06:27, vous avez écrit : Can't call method fetch_element on an undefined value at /usr/share/perl5/Config/Model/Backend/Debian/Dpkg/Copyright.pm line 121. Do you want me to fill a bug report in addition to this email? Yes, please. And also include the copyright file (or an extract) that shows the bug. Done, see 614776. All the best Dominique Best regards. -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ signature.asc Description: This is a digitally signed message part.
Re: New version of DEP-5 parser
Le vendredi 21 janvier 2011 21:16:59, Dominique Dumont a écrit : 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. I've just discovered now but config-edit fail when header section contain a License stanza. It fails with: Can't call method fetch_element on an undefined value at /usr/share/perl5/Config/Model/Backend/Debian/Dpkg/Copyright.pm line 121. Do you want me to fill a bug report in addition to this email? 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 Thanks for this tool Dominique Thomas Preud'homme [1] http://search.cpan.org/dist/Config-Model/ [2] http://ddumont.wordpress.com/2011/01/13/debian-copyright-dep5-parsereditor validatormigrator-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/ signature.asc Description: This is a digitally signed message part.
Re: New version of DEP-5 parser
Le mardi 22 février 2011 19:06:27, vous avez écrit : Can't call method fetch_element on an undefined value at /usr/share/perl5/Config/Model/Backend/Debian/Dpkg/Copyright.pm line 121. Do you want me to fill a bug report in addition to this email? Yes, please. And also include the copyright file (or an extract) that shows the bug. All the best Dominique -- 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110024.03068.domi.dum...@free.fr
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-devel-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
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
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
