Comment 7 for bug 685571

Hi James,

Thanks for your comments.

On Sat, 2011-01-29 at 13:52 +0000, James Ascroft-Leigh wrote:
> 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 -
binNMU's are intended for no-change rebuilds of existing packages,
they're not a wild card for having divergent source and binary package
versions. Also, binNMU's are not supported in Ubuntu (we don't allow
binary uploads). Allowing non-upload rebuilds is on the wishlist though,
but not implemented (bug 245594).

> * 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. -
> (and
> see also the merged bugs)

> * The substvars mechanism is invoked through debian/rules and
> thus theoretically the build dependencies are already
> installed.
I'm not sure I understand what you mean here? The build dependencies
are installed before substvars or debian/rules come into play at all
at the moment. Or is that what you're saying?

> 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.
> ) 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.
The concern with recreating packages is broader than just packages built
on Launchpad, it also covers local builds (which can't have a build job