Using dfsg versions with upstream that have 3 and 4 segmented version numbers

[Kilian Krause]

Hi guys,

as I've repeatedly seen problems with the snapshots and dfsg-version
repacking, this is a small heads-up to using dfsg repacking with new ~
version fix of dpkg with upstreams.

Short summary: Among others Asterisk has been bumped from 1.2.x to
1.2.x.y a couple of times and just so has zaptel, libpri etc.. Result of
this is that we're shipping 1.2.x.dfsg followed by 1.2.x.y.dfsg which is
supposed to be regarded as newer. Obviously this can be manually
adjusted while uploading with epochs and just shipping the .x.y version,
but there is a much nicer alternative: using ~dfsg rather than .dfsg.

Right now we've got:
[*] asterisk (1:1.2.13~dfsg-1) UNRELEASED; urgency=high
[ ] freepbx (2.1.3.dfsg-1) UNRELEASED; urgency=low
[ ] iaxmodem (0.1.14.dfsg-2) UNRELEASED; urgency=low
[ ] kiax (0.8.51.dfsg-2-1) unstable; urgency=low
[ ] opal (2.2.3.dfsg-3) UNRELEASED; urgency=low
[ ] openh323 (1.18.0.dfsg-2) UNRELEASED; urgency=low
[ ] op-panel (0.26.dfsg-4) UNRELEASED; urgency=low
[ ] stun (0.96.dfsg-3) UNRELEASED; urgency=low
[ ] yate (1.1.0-1.dfsg-1) UNRELEASED; urgency=low
[ ] zaptel (1:1.2.10.dfsg-2) UNRELEASED; urgency=low

in SVN. Of these asterisk is converted already. Whoever updates any of
these to new upstream release version, please do switch the .dfsg in
changelog and rules (the get-orig-source) target, so we'll get this
problem solved once and forever.

Thanks!

-- 
Best regards,
Kilian