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 -
> http://wiki.debian.org/binNMU
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. -
> 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.
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. 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.
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
URL).
Hi James,
Thanks for your comments.
On Sat, 2011-01-29 at 13:52 +0000, James Ascroft-Leigh wrote: wiki.debian. org/binNMU
> 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://
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 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.
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 /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.
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
URL).
Cheers,
Jelmer