[buildd-tools-devel] Bug#672711: Bug#672711: sbuild: --append-to-version should set source:Version substvar

[Roger Leigh]

clone 672711 -1
retitle -1 dpkg-source: Incorrect assumption setting source version
reassign -1 dpkg-dev
thanks

On Sat, May 12, 2012 at 08:32:11PM -0700, Geoffrey Thomas wrote:
> As you saw on #debian-devel about a week ago, Paul Wise noticed (as
> a result of running the debian-derivatives analysis scripts on
> Debathena, which uses --append-to-version for all builds) that
> builds with --append-to-version do not correctly report the
> original/source package version number in the Source: field of the
> binary control file and binary .changes file. Namely, the field is
> expected to contain something of the form "package (1.0)", not just
> "package", if the resulting binary package is not version 1.0. This
> works fine for sbuild's --binNMU option -- the binary package will
> be version e.g. 1.0+b1, but contain a Source: field of "package
> (1.0)".
> 
> On tracking this down a little further (and noticing that
> --append-to-version=+b2 did not exhibit this bug), I found that when
> dpkg-source generates substvars (in Dpkg::Substvar), it uses the
> following logic:
> 
> sub set_version_substvars {
>     my ($self, $version) = @_;
> 
>     $self->{'vars'}{'binary:Version'} = $version;
>     $self->{'vars'}{'source:Version'} = $version;
>     $self->{'vars'}{'source:Version'} =~ s/\+b[0-9]+$//;
>     [...]
> }
> 
> So the source:Version field is only correct when the binary version
> happens to end with a +bNNN (or when it is the same as the source
> version, of course). So sbuild did not need to specifically do
> anything about source:Version when --binNMU was the only option that
> changed the binary version from the source version, but this
> assumption is no longer true with --append-to-version.
> 
> I'm not sure what the right way to fix this is. Possibly sbuild
> itself should edit debian/substvars to change the source:Version
> field. I can't get --dpkg-source-opt=-Vsource:Version=1.0 to work,
> although maybe dpkg-source getting run before "Hack binNMU version"
> is relevant. Possibly dpkg-source gaining an option to be explicitly
> told the source package version is the most-right answer here, but
> would require changes in both sbuild and dpkg-dev.

Hi Raphäel,

In sbuild we allow additional extensions (in additional to +bn)
appended to the version number, which are used for custom rebuilds of
packages.  However, it looks like the above logic in dpkg-source is
only useful for binNMU versioning.

In sbuild, the way binNMUs have always been done is to create a
new changelog entry with the binNMU version, and then do a
binary-only build.  This works with the above logic.  However,
while this mechanism works, it's clearly a bit of a hack.

It would be great if there was a way to specify an additional
build version during a build to dpkg-buildpackage, which would
not necessarily require an updated changelog entry, but could
maybe be put into substvars as build:Version and so would hence
be a more generalised and flexible solution.  sbuild could then
adopt this for doing both binNMUs and other appended versions
which change this build version.  This could default to
binary:Version.  Alternatively, this could just be binary:Version
itself, since the source:Version would just be the changelog
version (special binNMU changelog entries no longer being
required).


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800