On Fri, Apr 09, 2010 at 11:04:26AM +0200, Martin Zobel-Helas wrote: > Hi, > > On Fri Apr 09, 2010 at 10:46:24 +0200, Christian Marillat wrote: > > Martin Zobel-Helas <[email protected]> writes: > > > > [...] > > > > > This seems to happen due to the "_" in the version number > > > (version_compare from Dpkg::Version, called by Devscripts::Versort). I > > > have currently no time to investigate any further. > > > > Yes, the use of Dpkg::Version is a bad idea, because _ in version number > > aren't allowed by Debian and thus rejected here. > > Debian Policy says about this: > > | upstream_version: > | > | This is the main part of the version number. It is usually the version > | number of the original ("upstream") package from which the .deb file has > | been made, if this is applicable. Usually this will be in the same > | format as that specified by the upstream author(s); however, it may need > | to be reformatted to fit into the package management system's format and > | comparison scheme. > | > | The comparison behavior of the package management system with respect to > | the upstream_version is described below. The upstream_version portion of > | the version number is mandatory. > | > | The upstream_version may contain only alphanumerics[32] and the > | characters . + - : ~ (full stop, plus, hyphen, colon, tilde) and should > | start with a digit. If there is no debian_revision then hyphens are not > | allowed; if there is no epoch then colons are not allowed. > > so yes, maybe we should not use Dpkg::Version for comparing it.
Interesting conclusion since the quoted part of policy specifies both that “it may need to be reformatted to fit into the package management system's format” and that the version “may contain only alphanumerics[32] and the characters . + - : ~”. This seems like precisely the reason we have uversionmangle support in uscan -- to mangle upstream's strange versions into something useful for Debian. I'm not strictly opposed to going back to the old behavior (which we can do using Dpkg::Version), but I think there should be a good reason to accept invalid versions. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[email protected]>
signature.asc
Description: Digital signature
