#684431 python3-defaults: policy violation: dash in version number of native package

Package:
src:python3-defaults
Source:
python3-defaults
Submitter:
Thorsten Glaser
Date:
2021-09-01 01:45:03 UTC
Severity:
minor
Tags:
#684431#5
Date:
2012-08-09 22:11:29 UTC
From:
To:
Hi,

just skimming recent changelogs I came across this gem:

python3-defaults (3.2.3-5) unstable; urgency=low
[…]
  * Change source format from native to 3.0 (native)
[…]

Now, obviously, this package has been using bogus version
numbers for quite a while. This bug merely reports this and
would like to remind the packagers of Policy §5.6.12 which
contains language forbidding the use of a dash/hyphen-minus
in a native package’s version. Not RC though.

Goodnight,
//mirabilos
#684431#10
Date:
2012-10-24 19:06:49 UTC
From:
To:
tags 684431 + wontfix
severity 684431 minor
thanks

these packages, and others like the gcc-4.x packages are split into the real and
the defaults packages and could be built from the same source again. I won't use
a version number which implies that this is a native package only.

  Matthias
#684431#19
Date:
2021-09-01 01:14:23 UTC
From:
To:
Hi!

This package uses a native source format, with a non-native version,
which is rather confusing (to unexperienced and experience packagers
alike) and subverts the semantics of both the source and version
formats. Which is a common source of accidental packaging bugs,
and makes handling of source packages more brittle by external tools.

This currently produces a lintian error, and with dpkg-dev 1.20.1 it
started producing warnings, but my intention is to eventually make
it error out, given the above.

Please, either use a non-native source format, or a native version,
so that these are coherent.

I do understand the appeal of the current usage in this package, as it
wants to represent the upstream versions faithfully. But there are
workable alternatives used by other similar default source packages:

  * Use a different revision separator, the common pattern would be to
    use «+», but it could also be a string. This has the advantage
    that it can be easily mapped and follows the current packaging
    practice.
  * Use an independent version, and set the binary package versions
    from debian/rules. For this package this would be more cumbersome
    and probably confusing given the existing version scheme.
  * Switch to use a non-native source format.

Thanks,
Guillem