bzr-builder

Bug #685571
Comment #7

Comment 7 for bug 685571

Revision history for this message

Jelmer Vernooij (jelmer) wrote on 2011-01-29: Re: [Bug 685571] Re: programmatic way to update upstream version string

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 -
> 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).

Cheers,

Jelmer

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 -
>      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).

Cheers,

Jelmer