Re: New version of DEP-5 parser
Le Sun, Jan 23, 2011 at 03:09:00PM +0100, Dominique Dumont a écrit : > > Config::Model was designed to handle configuration files where the concept of > unknown parameter does not apply. Dear Dominique, I think that it is completely fine. There is no guarantee that an extra field is used consistently across all the machine-readable copyright files. I think that they should simply propagated without modification. If package maintainers would like to use debian/copyright to vehiculate extra information, I think that it is their responsiblity to do it right as it is not a requirement from the Policy and currently there is no plan to harvest that data on a project-wide manner. If a revision of the format would bless a popular extra field into an optional or required field, a parser performing an upgrade could simply issue a warning when it detects that it was already present in the previous version. This gives a maximum of flexibility. If we make a barrier to the addition of extra fields, I think that it will send the wrong message to the developers who would like to explore evolutions on the use of debian/copyright. Lastly, I do not think that it is necessary to provide an automated upgrade facility for the files written with pre-CANDIDATE versions of the DEP, especially for optional fields. In summary, it is great to have your parser working on the current version of the DEP, recognising the required and optional fields. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20110124015637.gf12...@merveille.plessy.net
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
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: 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
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: Debian Linux OS /// Urgent
Dear Sir, Thank you very much, Best regards, Malvina Treuil Consultant Contrôle Commerce International International Trade Control Consultant Global Supply Chain GE Healthcare T +33 1 30 70 75 36 F +33 1 30 70 98 90 E malvina.tre...@ge.com 283 rue de la Minière 78530 Buc France GE imagination at work -Original Message- From: Yves-Alexis Perez [mailto:cor...@debian.org] Sent: Friday, January 21, 2011 3:04 PM To: debian-project@lists.debian.org Cc: Treuil, Malvina (GE Healthcare, consultant) Subject: Re: Debian Linux OS /// Urgent On mar., 2011-01-11 at 15:58 +0100, Yves-Alexis Perez wrote: > (with my ANSSI hat on) > > On mar., 2011-01-11 at 10:32 +0100, Treuil, Malvina (GE Healthcare, > consultant) wrote: > > Dear Madam, Dear Sir, The company I work for GEHC buys the software > > containing the following encryption mean : Debian Linux. > > I would like to check with you if this encryption mean have already > > been declared to the French authorities (ANSSI). If yes, could you > > please provide me with the ANSSI declaration file number and copy? > > As we need to have them in case of an audit in France. > > Debian Project didn't made any declaration for crypto stuff to the > French authorities. For reference, crypto supply and import are free > (but subject to declaration), while export (from France) can be > subject to authorization *if it's easy for an end user to change the > embedded crypto*, else it's only declaration. More info can be found > at http://www.ssi.gouv.fr/site_rubrique58.html (in French) > > I (with my Debian hat) did the declaration for supply/import/export > (on the basis that changing the crypto usually needs a recompilation, > which is not immediate for an end user, so it's not "easy" in the > original sense). > > The official declaration should be available soon, I'll keep you posted. Sorry it took so long. The declaration file number is 1101027. Scans of the various documents are available at http://people.debian.org/~corsac/anssi/ (in French). It might be a good idea to put those somewhere on the website (not sure if we have a place for that though) in case other people will need it. Obviously, the timing is not perfect, as I'll have to make another declaration for Squeeze when it's out, but I though it was a good idea to have it first for Lenny, since the requester needed it right now and people will still use Lenny for some time. If you have any question, please ask. -- Yves-Alexis -- 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/2746ffcb35e1a248bf5a482d0b82ffc201092...@budmlvem05.e2k.ad.ge.com
Re: [DEP5] License field in the first paragraph ?
On la, 2011-01-22 at 14:47 -0800, Steve Langasek wrote: > So a License could appear without a Copyright (to indicate the effective > license of a work), but a Copyright should not appear without a License. > > If that's true, I think it's important to call it out in the spec. I'll add the following words to Charles's patch: "It is possible to use only License in the header paragraph, but Copyright alone makes no sense." I hope that's acceptable. -- 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/1295772127.2989.25.ca...@havelock.lan
