Bug#751437: dpkg-dev: support ${source:Version} substvar in Build-Depends
Control: forcemerge 677474 -1
Control: retitle -1 dpkg-dev: support substvars in Build-Depends
On Fri, 2014-06-13 at 19:12:25 +0200, Guillem Jover wrote:
On Thu, 2014-06-12 at 22:40:40 +0200, Helmut Grohne wrote:
Package: dpkg-dev
Version: dpkg_1.17.10
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Let us revisit a less intrusive variant of #677474. My request is to
enable interpolation of ${source:Version} in Build-Depends and friends.
Of course this arises from a practical need:
Quite a few packages use the binaries created in the process of building
the package. A primary example affecting 200 packages is help2man.
Unfortunately those binaries are not always executable. Most notably
they are not executable when cross compiling. Rather than resorting to
ugly hacks it would be nice to just use the build version of those tools
to generate manual pages or facilitate other tasks. In most cases that
would amount to:
Source: foo
Build-Depends: foo profile.cross
In many cases this would be correct, but ideally we want to ensure that
the manual pages created match the source. So the dependency needs to be
rather stricter:
Build-Depends: foo (= ${source:Version}) profile.cross
This use of substvars would not pose any problems for regular
build-ability of the package, because the dependency is not evaluated in
the absence of the cross profile.
While this is strictly true, it's still problematic. It unconditionally
adds the substvars in dpkg-source, which opens for the possibility of
accidental misuse, it also can only set correctly the source:Version,
not the binary:Version substvar. Also dpkg-checkbuilddeps does not
have any kind of knowledge about substvars, so it will then become
unusable when cross-compiling those packages.
TBH, I've always found the help2man usage dubious, because it usually
adds marginal information to something that's already available through
just «cmd --help», and seems prone to cause problems. It feels to just
be there to satisfy the Debian desire for a man page per binary.
I'd rather see this specific problem solved in a way that benefits
upstream, so either changing their build system to build for the
host and build systems, so that help2man can be used even when
cross-building, or by switching away from help2man and providing
static man pages.
Given the above, that this ends up having the same problems as the
other general bug, and that the specific case of help2man was agreed
in the bootstrap sprint in Paris to be fixed in a different way, I'm
merging these bug reports.
Thanks,
Guillem
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751437: dpkg-dev: support ${source:Version} substvar in Build-Depends
Hi!
On Thu, 2014-06-12 at 22:40:40 +0200, Helmut Grohne wrote:
Package: dpkg-dev
Version: dpkg_1.17.10
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Let us revisit a less intrusive variant of #677474. My request is to
enable interpolation of ${source:Version} in Build-Depends and friends.
Of course this arises from a practical need:
Quite a few packages use the binaries created in the process of building
the package. A primary example affecting 200 packages is help2man.
Unfortunately those binaries are not always executable. Most notably
they are not executable when cross compiling. Rather than resorting to
ugly hacks it would be nice to just use the build version of those tools
to generate manual pages or facilitate other tasks. In most cases that
would amount to:
Source: foo
Build-Depends: foo profile.cross
In many cases this would be correct, but ideally we want to ensure that
the manual pages created match the source. So the dependency needs to be
rather stricter:
Build-Depends: foo (= ${source:Version}) profile.cross
This use of substvars would not pose any problems for regular
build-ability of the package, because the dependency is not evaluated in
the absence of the cross profile.
While this is strictly true, it's still problematic. It unconditionally
adds the substvars in dpkg-source, which opens for the possibility of
accidental misuse, it also can only set correctly the source:Version,
not the binary:Version substvar. Also dpkg-checkbuilddeps does not
have any kind of knowledge about substvars, so it will then become
unusable when cross-compiling those packages.
TBH, I've always found the help2man usage dubious, because it usually
adds marginal information to something that's already available through
just «cmd --help», and seems prone to cause problems. It feels to just
be there to satisfy the Debian desire for a man page per binary.
I'd rather see this specific problem solved in a way that benefits
upstream, so either changing their build system to build for the
host and build systems, so that help2man can be used even when
cross-building, or by switching away from help2man and providing
static man pages.
Thanks,
Guillem
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751437: dpkg-dev: support ${source:Version} substvar in Build-Depends
Package: dpkg-dev
Version: dpkg_1.17.10
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Dear dpkg maintainers,
Let us revisit a less intrusive variant of #677474. My request is to
enable interpolation of ${source:Version} in Build-Depends and friends.
Of course this arises from a practical need:
Quite a few packages use the binaries created in the process of building
the package. A primary example affecting 200 packages is help2man.
Unfortunately those binaries are not always executable. Most notably
they are not executable when cross compiling. Rather than resorting to
ugly hacks it would be nice to just use the build version of those tools
to generate manual pages or facilitate other tasks. In most cases that
would amount to:
Source: foo
Build-Depends: foo profile.cross
In many cases this would be correct, but ideally we want to ensure that
the manual pages created match the source. So the dependency needs to be
rather stricter:
Build-Depends: foo (= ${source:Version}) profile.cross
This use of substvars would not pose any problems for regular
build-ability of the package, because the dependency is not evaluated in
the absence of the cross profile.
Thanks for considering
Helmut
diff -Nru dpkg-1.17.10/debian/changelog dpkg-1.17.10+nmu1/debian/changelog
--- dpkg-1.17.10/debian/changelog 2014-06-05 21:05:39.0 +0200
+++ dpkg-1.17.10+nmu1/debian/changelog 2014-06-12 22:26:03.0 +0200
@@ -1,3 +1,10 @@
+dpkg (1.17.10+nmu1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Support interpolating ${source:Version} in Build-Depends. Closes: #-1
+
+ -- Helmut Grohne hel...@subdivi.de Thu, 12 Jun 2014 22:25:43 +0200
+
dpkg (1.17.10) unstable; urgency=medium
[ Guillem Jover ]
diff -Nru dpkg-1.17.10/scripts/dpkg-source.pl
dpkg-1.17.10+nmu1/scripts/dpkg-source.pl
--- dpkg-1.17.10/scripts/dpkg-source.pl 2014-05-30 18:30:50.0 +0200
+++ dpkg-1.17.10+nmu1/scripts/dpkg-source.pl2014-06-12 22:25:39.0
+0200
@@ -341,6 +341,7 @@
my ($ok, $error) = version_check($v);
error($error) unless $ok;
$fields-{$_} = $v;
+ $substvars-set_version_substvars($v);
} elsif (m/^Binary-Only$/) {
error(_g('building source for a binary-only release'))
if $v eq 'yes' and $options{opmode} eq '-b';
