Bug#672711: sbuild: --append-to-version should set source:Version substvar
tags 672711 + patch
tags 681292 + patch
thanks
On Thu, 12 Jul 2012, Raphael Hertzog wrote:
If you tag the changelog entry with binary-only=yes then
dpkg-gencontrol will use the former changelog entry to find
out the version to put in ${source:Version}.
ftplib (3.1-1-9+b1) unstable; urgency=low, binary-only=yes
You should update --append-to-version to use this mechanism too.
Hi sbuild maintainers,
I was checking on the Debian bugs I opened to see what their status was,
and didn't see progress on this, so I wanted to check to see if we were
waiting on anything from dpkg, or could fix this now in sbuild. The
conversation in #681292 seemd to indicate that you were okay with this
approach.
The debian-672711 branch of https://github.com/geofft/sbuild.git has the
following patch and a changelog entry:
--- a/lib/Sbuild/Build.pm
+++ b/lib/Sbuild/Build.pm
@@ -1324,7 +1324,7 @@ sub build {
}
$dists = $self-get_conf('DISTRIBUTION');
- print F $name ($NMUversion) $dists; urgency=low\n\n;
+ print F $name ($NMUversion) $dists; urgency=low,
binary-only=yes\n\n;
if ($self-get_conf('APPEND_TO_VERSION')) {
print F * Append , $self-get_conf('APPEND_TO_VERSION'),
to version number; no source changes\n;
Can you merge it?
Thanks,
--
Geoffrey Thomas
geo...@mit.edu
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672711: [buildd-tools-devel] Bug#672711: Bug#672711: sbuild: --append-to-version should set source:Version substvar
Hi,
On Sun, 13 May 2012, Roger Leigh wrote:
The current situation, as I see it, is that the versions in
debian/changelog specify the source version. The binary
version is always equal to the source version. However, when
the version is +bn we treat this specially and have different
source and binary versions.
As you probably saw with my last bug report, there's now a way
for you to deal with this wishlist but it still involves messing
with the changelog.
If you tag the changelog entry with binary-only=yes then
dpkg-gencontrol will use the former changelog entry to find
out the version to put in ${source:Version}.
ftplib (3.1-1-9+b1) unstable; urgency=low, binary-only=yes
You should update --append-to-version to use this mechanism too.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672711: [buildd-tools-devel] Bug#672711: sbuild: --append-to-version should set source:Version substvar
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/Linuxhttp://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
Bug#672711: [buildd-tools-devel] Bug#672711: Bug#672711: sbuild: --append-to-version should set source:Version substvar
On Sun, May 13, 2012 at 10:13:53AM +0100, Roger Leigh wrote: 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). Just to expand on this: The current situation, as I see it, is that the versions in debian/changelog specify the source version. The binary version is always equal to the source version. However, when the version is +bn we treat this specially and have different source and binary versions. I think it would be much nicer if rather than having to use heuristics, we could simply set the binary version directly (with no changelog hacking required). If dpkg-buildpackage and/or the other dpkg tools could provide an option to override the binary version from its default (source) version, this would provide a clean, reliable mechanism. It also need not provide arbitrary versions; appending the build version to the source version would be entirely sufficient. Such a mechanism could then be used by sbuild for binNMUs, and other appended build versions. And, more importantly, the functionality would be exposed in a standard manner, so the versioning mechanism would not be tied to how sbuild does binNMUs, and would be generally usable. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://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
Bug#672711: sbuild: --append-to-version should set source:Version substvar
Package: sbuild
Version: 0.62.6-1
Hi Roger,
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.
--
Geoffrey Thomas
geo...@mit.edu
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
