Comment 6 for bug 685571

I have been doing some research into this and I found out some
information that might be pertinent:

   * The versions numbers of binary packages are allowed to
     differ from the version numbers of their source package -
     http://wiki.debian.org/binNMU

   * Several people have tried, over many years, to use the
     substvars mechanism in "critical" fields such as the package
     name and the version number. There are some
     documented "wontfix" "wishlist" bugs against dpkg preventing
     this from working properly. I have not tried this myself to
     see if it has been fixed yet. -
     http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=66336 (and
     see also the merged bugs)

   * The substvars mechanism is invoked through debian/rules and
     thus theoretically the build dependencies are already
     installed.

My proposal would be to check (and fix if necessary) the use of
substvars to set the version number of DEBIAN/control. In order to
satisfy concerns about recreating the package, I think there are
a few options. My favourite is to have Launchpad refuse to
publish [dynamically named/numbered] packages unless the build job
URL (e.g. https://code.launchpad.net/~jwal/+archive/wkhtmltopdf/+buildjob/1970431
) is included in a new field called "Build-Job:" in the binary
package control file. The URL could be passed through from the
recipe to the debian/rules file as an environment variable.