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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org