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.
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 wiki.debian. org/binNMU
differ from the version numbers of their source package -
http://
* Several people have tried, over many years, to use the bugs.debian. org/cgi- bin/bugreport. cgi?bug= 66336 (and
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://
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 /code.launchpad .net/~jwal/ +archive/ wkhtmltopdf/ +buildjob/ 1970431
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:/
) 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.