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

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


[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/

Reply to: