Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#657401: dpkg-buildpackage: support output directory other than ..
3,111 views
Skip to first unread message
Don Armstrong
Jan 25, 2012, 6:40:02 PM1/25/12
to
Package: dpkg-dev
Severity: wishlist
Version: dpkg/1.14.25
Currently, it is not trivial to have dpkg-buildpackage (or debuild)
output a build package to a directory other than '..'. Support of a
--output directory option with a default of '..' would avoid other
tools having to parse the .changes file generated to move output files
to a desired directory. [And would also avoid stomping on existing
files even if one were to parse the .changes file properly.]
Don Armstrong
--
"What, now?"
"Soon equates to good, later to worse, Uagen Zlepe, scholar.
Therefore, immediacy."
-- Iain M. Banks _Look to Windward_ p 213
http://www.donarmstrong.com http://rzlab.ucr.edu
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Severity: wishlist
Version: dpkg/1.14.25
Currently, it is not trivial to have dpkg-buildpackage (or debuild)
output a build package to a directory other than '..'. Support of a
--output directory option with a default of '..' would avoid other
tools having to parse the .changes file generated to move output files
to a desired directory. [And would also avoid stomping on existing
files even if one were to parse the .changes file properly.]
Don Armstrong
--
"What, now?"
"Soon equates to good, later to worse, Uagen Zlepe, scholar.
Therefore, immediacy."
-- Iain M. Banks _Look to Windward_ p 213
http://www.donarmstrong.com http://rzlab.ucr.edu
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Don Armstrong
Jan 26, 2012, 12:10:02 AM1/26/12
to
On Thu, 26 Jan 2012, Guillem Jover wrote:
> I implemented this, but then realized that it cannot be done
> cleanly, as dpkg-deb is called from inside debian/rules and will
> always place the binary packages under «..», so dpkg-buildpackage
> would need to move the files itself afterwards. While that could be
> done, it might not avoid the problem you refer to.
Hrm; true. I actually wanted this primarily for debuild -S, but
solving it for everything is probably necessary to solve it at all.
The hack of sending an env option through to dpkg-deb is all kinds of
ugly...
Don Armstrong
--
"I'm a rational being--of a sort--rational enough, at least, to see the
symptoms of insanity around me. And I'm human, the same as the people
I think of as victims when my guard drops. It's at least possible I'm
even crazier than my fellows, whom I'm tempted to pity.
"There seems only one thing to do, and that's get drunk"
-- Chad C. Mulligan (John Brunner _Stand On Zanzibar_ p390)
> I implemented this, but then realized that it cannot be done
> cleanly, as dpkg-deb is called from inside debian/rules and will
> always place the binary packages under «..», so dpkg-buildpackage
> would need to move the files itself afterwards. While that could be
> done, it might not avoid the problem you refer to.
Hrm; true. I actually wanted this primarily for debuild -S, but
solving it for everything is probably necessary to solve it at all.
The hack of sending an env option through to dpkg-deb is all kinds of
ugly...
Don Armstrong
--
"I'm a rational being--of a sort--rational enough, at least, to see the
symptoms of insanity around me. And I'm human, the same as the people
I think of as victims when my guard drops. It's at least possible I'm
even crazier than my fellows, whom I'm tempted to pity.
"There seems only one thing to do, and that's get drunk"
-- Chad C. Mulligan (John Brunner _Stand On Zanzibar_ p390)
Guillem Jover
Jan 26, 2012, 12:10:02 AM1/26/12
to
On Wed, 2012-01-25 at 15:28:41 -0800, Don Armstrong wrote:
> Package: dpkg-dev
> Severity: wishlist
> Version: dpkg/1.14.25
>
> Currently, it is not trivial to have dpkg-buildpackage (or debuild)
> output a build package to a directory other than '..'. Support of a
> --output directory option with a default of '..' would avoid other
> tools having to parse the .changes file generated to move output files
> to a desired directory. [And would also avoid stomping on existing
> files even if one were to parse the .changes file properly.]
> Package: dpkg-dev
> Severity: wishlist
> Version: dpkg/1.14.25
>
> Currently, it is not trivial to have dpkg-buildpackage (or debuild)
> output a build package to a directory other than '..'. Support of a
> --output directory option with a default of '..' would avoid other
> tools having to parse the .changes file generated to move output files
> to a desired directory. [And would also avoid stomping on existing
> files even if one were to parse the .changes file properly.]
I implemented this, but then realized that it cannot be done cleanly,
as dpkg-deb is called from inside debian/rules and will always place
the binary packages under «..», so dpkg-buildpackage would need to
move the files itself afterwards. While that could be done, it might
not avoid the problem you refer to.
regards,
as dpkg-deb is called from inside debian/rules and will always place
the binary packages under «..», so dpkg-buildpackage would need to
move the files itself afterwards. While that could be done, it might
not avoid the problem you refer to.
guillem
Raphael Hertzog
Jan 26, 2012, 2:50:01 AM1/26/12
to
Hi,
On Wed, 25 Jan 2012, Don Armstrong wrote:
> On Thu, 26 Jan 2012, Guillem Jover wrote:
> > I implemented this, but then realized that it cannot be done
> > cleanly, as dpkg-deb is called from inside debian/rules and will
> > always place the binary packages under «..», so dpkg-buildpackage
> > would need to move the files itself afterwards. While that could be
> > done, it might not avoid the problem you refer to.
>
> Hrm; true. I actually wanted this primarily for debuild -S, but
> solving it for everything is probably necessary to solve it at all.
Note that dpkg-source also creates files in the current directory and
expect to find files in the current directory (and dpkg-buildpackage
changes the current directory to ".." for the needs of dpkg-source).
So if you change the current directory to your output directory, you also
have to do something to ensure that dpkg-source keeps on finding the orig
tarballs.
> The hack of sending an env option through to dpkg-deb is all kinds of
> ugly...
Why would it be more ugly than dpkg-buildpackage -j setting
DEB_BUILD_OPTIONS="parallel"?
Of course, if there would be no constraints, I would not pick up an env
variable as preferred way to pass options but there are many tools
who are accepting options through the environment (think GZIP,
TAR_OPTIONS, etc.). I don't see why we couldn't do that.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
On Wed, 25 Jan 2012, Don Armstrong wrote:
> On Thu, 26 Jan 2012, Guillem Jover wrote:
> > I implemented this, but then realized that it cannot be done
> > cleanly, as dpkg-deb is called from inside debian/rules and will
> > always place the binary packages under «..», so dpkg-buildpackage
> > would need to move the files itself afterwards. While that could be
> > done, it might not avoid the problem you refer to.
>
> Hrm; true. I actually wanted this primarily for debuild -S, but
> solving it for everything is probably necessary to solve it at all.
expect to find files in the current directory (and dpkg-buildpackage
changes the current directory to ".." for the needs of dpkg-source).
So if you change the current directory to your output directory, you also
have to do something to ensure that dpkg-source keeps on finding the orig
tarballs.
> The hack of sending an env option through to dpkg-deb is all kinds of
> ugly...
DEB_BUILD_OPTIONS="parallel"?
Of course, if there would be no constraints, I would not pick up an env
variable as preferred way to pass options but there are many tools
who are accepting options through the environment (think GZIP,
TAR_OPTIONS, etc.). I don't see why we couldn't do that.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
Guillem Jover
Jan 26, 2012, 6:50:03 PM1/26/12
to
On Thu, 2012-01-26 at 08:29:51 +0100, Raphael Hertzog wrote:
> On Wed, 25 Jan 2012, Don Armstrong wrote:
> > On Thu, 26 Jan 2012, Guillem Jover wrote:
> > > I implemented this, but then realized that it cannot be done
> > > cleanly, as dpkg-deb is called from inside debian/rules and will
> > > always place the binary packages under «..», so dpkg-buildpackage
> > > would need to move the files itself afterwards. While that could be
> > > done, it might not avoid the problem you refer to.
> >
> > Hrm; true. I actually wanted this primarily for debuild -S, but
> > solving it for everything is probably necessary to solve it at all.
>
> Note that dpkg-source also creates files in the current directory and
> expect to find files in the current directory (and dpkg-buildpackage
> changes the current directory to ".." for the needs of dpkg-source).
>
> So if you change the current directory to your output directory, you also
> have to do something to ensure that dpkg-source keeps on finding the orig
> tarballs.
That's already handled by passing the sourcedir path to dpkg-source,
> On Wed, 25 Jan 2012, Don Armstrong wrote:
> > On Thu, 26 Jan 2012, Guillem Jover wrote:
> > > I implemented this, but then realized that it cannot be done
> > > cleanly, as dpkg-deb is called from inside debian/rules and will
> > > always place the binary packages under «..», so dpkg-buildpackage
> > > would need to move the files itself afterwards. While that could be
> > > done, it might not avoid the problem you refer to.
> >
> > Hrm; true. I actually wanted this primarily for debuild -S, but
> > solving it for everything is probably necessary to solve it at all.
>
> Note that dpkg-source also creates files in the current directory and
> expect to find files in the current directory (and dpkg-buildpackage
> changes the current directory to ".." for the needs of dpkg-source).
>
> So if you change the current directory to your output directory, you also
> have to do something to ensure that dpkg-source keeps on finding the orig
> tarballs.
the only change I had to do was to switch from relative paths to
absolute ones in that case.
> > The hack of sending an env option through to dpkg-deb is all kinds of
> > ugly...
>
> Why would it be more ugly than dpkg-buildpackage -j setting
> DEB_BUILD_OPTIONS="parallel"?
if at all, which does not have other defined ways to pass options to it.
Passing default options to dpkg-deb which is a sub-child, might be
unreliable, depending on how the build process is handled, if there's
environment cleanup from whoever ends up calling it, it does not
necessarily need to be debian/rules for example, etc.
> Of course, if there would be no constraints, I would not pick up an env
> variable as preferred way to pass options but there are many tools
> who are accepting options through the environment (think GZIP,
> TAR_OPTIONS, etc.). I don't see why we couldn't do that.
path for the deb. Environment variables are always used to set
option defaults (not commands) that always get overridden by the
command line, doing otherwise would be extremely confusing, and it's
just ugly.
In the end this comes down to the way or build system is currently
designed, in that debian/rules is in charge of generating the resulting
binary packages, which makes some global changes more difficult.
regards,
guillem
Raphael Hertzog
Jan 27, 2012, 2:50:01 AM1/27/12
to
On Fri, 27 Jan 2012, Guillem Jover wrote:
> > Of course, if there would be no constraints, I would not pick up an env
> > variable as preferred way to pass options but there are many tools
> > who are accepting options through the environment (think GZIP,
> > TAR_OPTIONS, etc.). I don't see why we couldn't do that.
>
> For starters all current invokations already use an explicit destination
> path for the deb.
Right, this is the real blocker. In most cases, dpkg-deb doesn't decide of
> > Of course, if there would be no constraints, I would not pick up an env
> > variable as preferred way to pass options but there are many tools
> > who are accepting options through the environment (think GZIP,
> > TAR_OPTIONS, etc.). I don't see why we couldn't do that.
>
> For starters all current invokations already use an explicit destination
> path for the deb.
the location, it's the caller that does (usually dh_builddeb).
> Environment variables are always used to set
> option defaults (not commands) that always get overridden by the
> command line, doing otherwise would be extremely confusing, and it's
> just ugly.
command...
> In the end this comes down to the way or build system is currently
> designed, in that debian/rules is in charge of generating the resulting
> binary packages, which makes some global changes more difficult.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
Guillem Jover
Jan 27, 2012, 4:10:01 AM1/27/12
to
On Fri, 2012-01-27 at 08:29:53 +0100, Raphael Hertzog wrote:
> On Fri, 27 Jan 2012, Guillem Jover wrote:
> > Environment variables are always used to set
> > option defaults (not commands) that always get overridden by the
> > command line, doing otherwise would be extremely confusing, and it's
> > just ugly.
>
> Sure. But a directory to use would certainly be an option and not a
> command...
Right, but the pathname is (optionally) passed as part of the command,
> On Fri, 27 Jan 2012, Guillem Jover wrote:
> > Environment variables are always used to set
> > option defaults (not commands) that always get overridden by the
> > command line, doing otherwise would be extremely confusing, and it's
> > just ugly.
>
> Sure. But a directory to use would certainly be an option and not a
> command...
not as an option, in addition it (almost) always gets passed, at least
from source packages. So it would still go against the principle that
environment vars do not override command line options, because the
caller explicitly passed a pathname not a filename for the deb, an
output dir would override that.
So it would only be ok on invokations w/o an explicit pathname argument,
or I guess just a filename. For other cases consider we'd either have to
strip any directory components from the pathname given on the command
line or the user would need to pass an output dir one level down the
path so that the ../ would get neutralized.
> > In the end this comes down to the way or build system is currently
> > designed, in that debian/rules is in charge of generating the resulting
> > binary packages, which makes some global changes more difficult.
>
> Yes.
several times, to look into a new design that would move things outside
the packaging, so that for example dpkg-deb would be done externally.
For example the RPM source format has some of these properties, but has
other problems of its own.
thanks,
guillem
Nicholas Brown
Mar 15, 2021, 3:40:03 PM3/15/21
to
I could imagine the patch below, which I started looking at some time ago but never
got around to coming back to, could form a start at implementing this.
It was just the obvious paths within the script itself, but the various calls to dpkg-source,
dpkg-genbuildinfo, dpkg-genchanges, that all accept output options, still need to be
modified to pass this new argument.
diff --git a/scripts/dpkg-buildpackage.pl b/scripts/dpkg-buildpackage.pl
index aacb831..af50b75 100755
--- a/scripts/dpkg-buildpackage.pl
+++ b/scripts/dpkg-buildpackage.pl
@@ -80,6 +80,7 @@ sub usage {
-d, --no-check-builddeps do not check build dependencies and conflicts.
--ignore-builtin-builddeps
do not check builtin build dependencies.
+ -o, --output-dir=<dir> path to put output files in. (default is ../)
-P, --build-profiles=<profiles>
assume comma-separated build <profiles> as active.
--rules-requires-root assume legacy Rules-Requires-Root field value.
@@ -182,6 +183,7 @@ my $changedby;
my $desc;
my @buildinfo_opts;
my @changes_opts;
+my $outdir = "..";
my %target_legacy_root = map { $_ => 1 } qw(
clean binary binary-arch binary-indep
);
@@ -301,6 +303,8 @@ while (@ARGV) {
$postclean = 0;
} elsif (/^--sanitize-env$/) {
$sanitize_env = 1;
+ } elsif (/^-o(.*)$/ or /^--output-dir=(.*)$/) {
+ $outdir = $1;
} elsif (/^-t$/ or /^--host-type$/) {
$host_type = shift; # Order DOES matter!
} elsif (/^-t(.*)$/ or /^--host-type=(.*)$/) {
@@ -598,7 +602,7 @@ push @changes_opts, "-e$changedby" if defined $changedby;
push @changes_opts, "-v$since" if defined $since;
push @changes_opts, "-C$desc" if defined $desc;
-my $chg = "../$pva.changes";
+my $chg = "$outdir/$pva.changes";
my $changes = Dpkg::Control->new(type => CTRL_FILE_CHANGES);
printcmd("dpkg-genchanges @changes_opts >$chg");
@@ -639,12 +643,12 @@ if ($signsource) {
# Recompute the checksums as the .dsc has changed now.
my $buildinfo = Dpkg::Control->new(type => CTRL_FILE_BUILDINFO);
- $buildinfo->load("../$pva.buildinfo");
+ $buildinfo->load("$outdir/$pva.buildinfo");
my $checksums = Dpkg::Checksums->new();
$checksums->add_from_control($buildinfo);
- $checksums->add_from_file("../$pv.dsc", update => 1, key => "$pv.dsc");
+ $checksums->add_from_file("$outdir/$pv.dsc", update => 1, key => "$pv.dsc");
$checksums->export_to_control($buildinfo);
- $buildinfo->save("../$pva.buildinfo");
+ $buildinfo->save("$outdir/$pva.buildinfo");
}
if ($signbuildinfo && signfile("$pva.buildinfo")) {
error(g_('failed to sign %s file'), '.buildinfo');
@@ -653,9 +657,9 @@ if ($signsource or $signbuildinfo) {
# Recompute the checksums as the .dsc and/or .buildinfo have changed.
my $checksums = Dpkg::Checksums->new();
$checksums->add_from_control($changes);
- $checksums->add_from_file("../$pv.dsc", update => 1, key => "$pv.dsc")
+ $checksums->add_from_file("$outdir/$pv.dsc", update => 1, key => "$pv.dsc")
if $signsource;
- $checksums->add_from_file("../$pva.buildinfo", update => 1, key => "$pva.buildinfo");
+ $checksums->add_from_file("$outdir/$pva.buildinfo", update => 1, key => "$pva.buildinfo");
$checksums->export_to_control($changes);
delete $changes->{'Checksums-Md5'};
update_files_field($changes, $checksums, "$pv.dsc")
@@ -858,7 +862,7 @@ sub signfile {
my $signfile = "$signdir/$file";
# Make sure the file to sign ends with a newline.
- copy("../$file", $signfile);
+ copy("$outdir/$file", $signfile);
open my $signfh, '>>', $signfile or syserr(g_('cannot open %s'), $signfile);
print { $signfh } "\n";
close $signfh or syserr(g_('cannot close %s'), $signfile);
@@ -868,8 +872,8 @@ sub signfile {
'--output', "$signfile.asc", $signfile);
my $status = $?;
if ($status == 0) {
- move("$signfile.asc", "../$file")
- or syserror(g_('cannot move %s to %s'), "$signfile.asc", "../$file");
+ move("$signfile.asc", "$outdir/$file")
+ or syserror(g_('cannot move %s to %s'), "$signfile.asc", "$outdir/$file");
}
print "\n";
index aacb831..af50b75 100755
--- a/scripts/dpkg-buildpackage.pl
+++ b/scripts/dpkg-buildpackage.pl
@@ -80,6 +80,7 @@ sub usage {
-d, --no-check-builddeps do not check build dependencies and conflicts.
--ignore-builtin-builddeps
do not check builtin build dependencies.
+ -o, --output-dir=<dir> path to put output files in. (default is ../)
-P, --build-profiles=<profiles>
assume comma-separated build <profiles> as active.
--rules-requires-root assume legacy Rules-Requires-Root field value.
@@ -182,6 +183,7 @@ my $changedby;
my $desc;
my @buildinfo_opts;
my @changes_opts;
+my $outdir = "..";
my %target_legacy_root = map { $_ => 1 } qw(
clean binary binary-arch binary-indep
);
@@ -301,6 +303,8 @@ while (@ARGV) {
$postclean = 0;
} elsif (/^--sanitize-env$/) {
$sanitize_env = 1;
+ } elsif (/^-o(.*)$/ or /^--output-dir=(.*)$/) {
+ $outdir = $1;
} elsif (/^-t$/ or /^--host-type$/) {
$host_type = shift; # Order DOES matter!
} elsif (/^-t(.*)$/ or /^--host-type=(.*)$/) {
@@ -598,7 +602,7 @@ push @changes_opts, "-e$changedby" if defined $changedby;
push @changes_opts, "-v$since" if defined $since;
push @changes_opts, "-C$desc" if defined $desc;
-my $chg = "../$pva.changes";
+my $chg = "$outdir/$pva.changes";
my $changes = Dpkg::Control->new(type => CTRL_FILE_CHANGES);
printcmd("dpkg-genchanges @changes_opts >$chg");
@@ -639,12 +643,12 @@ if ($signsource) {
# Recompute the checksums as the .dsc has changed now.
my $buildinfo = Dpkg::Control->new(type => CTRL_FILE_BUILDINFO);
- $buildinfo->load("../$pva.buildinfo");
+ $buildinfo->load("$outdir/$pva.buildinfo");
my $checksums = Dpkg::Checksums->new();
$checksums->add_from_control($buildinfo);
- $checksums->add_from_file("../$pv.dsc", update => 1, key => "$pv.dsc");
+ $checksums->add_from_file("$outdir/$pv.dsc", update => 1, key => "$pv.dsc");
$checksums->export_to_control($buildinfo);
- $buildinfo->save("../$pva.buildinfo");
+ $buildinfo->save("$outdir/$pva.buildinfo");
}
if ($signbuildinfo && signfile("$pva.buildinfo")) {
error(g_('failed to sign %s file'), '.buildinfo');
@@ -653,9 +657,9 @@ if ($signsource or $signbuildinfo) {
# Recompute the checksums as the .dsc and/or .buildinfo have changed.
my $checksums = Dpkg::Checksums->new();
$checksums->add_from_control($changes);
- $checksums->add_from_file("../$pv.dsc", update => 1, key => "$pv.dsc")
+ $checksums->add_from_file("$outdir/$pv.dsc", update => 1, key => "$pv.dsc")
if $signsource;
- $checksums->add_from_file("../$pva.buildinfo", update => 1, key => "$pva.buildinfo");
+ $checksums->add_from_file("$outdir/$pva.buildinfo", update => 1, key => "$pva.buildinfo");
$checksums->export_to_control($changes);
delete $changes->{'Checksums-Md5'};
update_files_field($changes, $checksums, "$pv.dsc")
@@ -858,7 +862,7 @@ sub signfile {
my $signfile = "$signdir/$file";
# Make sure the file to sign ends with a newline.
- copy("../$file", $signfile);
+ copy("$outdir/$file", $signfile);
open my $signfh, '>>', $signfile or syserr(g_('cannot open %s'), $signfile);
print { $signfh } "\n";
close $signfh or syserr(g_('cannot close %s'), $signfile);
@@ -868,8 +872,8 @@ sub signfile {
'--output', "$signfile.asc", $signfile);
my $status = $?;
if ($status == 0) {
- move("$signfile.asc", "../$file")
- or syserror(g_('cannot move %s to %s'), "$signfile.asc", "../$file");
+ move("$signfile.asc", "$outdir/$file")
+ or syserror(g_('cannot move %s to %s'), "$signfile.asc", "$outdir/$file");
}
print "\n";
Guillem Jover
Mar 17, 2021, 9:20:04 PM3/17/21
to
On Mon, 2020-03-15 at 19:26:14 +0000, Nicholas Brown wrote:
> I could imagine the patch below, which I started looking at some time ago
> but never
> got around to coming back to, could form a start at implementing this.
This is pretty close to what I initially did, and mentioned on my first
> I could imagine the patch below, which I started looking at some time ago
> but never
> got around to coming back to, could form a start at implementing this.
reply to the bug.
<https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/commit/?h=pu/dpkg-buildpackage-build-outputdir>
> It was just the obvious paths within the script itself, but the various
> calls to dpkg-source,
> dpkg-genbuildinfo, dpkg-genchanges, that all accept output options, still
> need to be
> modified to pass this new argument.
from within debian/rules, directly or indirectly via debhelper. Where
even if debhelper would handle this as Philipp Hahn suggested, dpkg
could not rely on that as this is a package-specific implementation
detail.
Until and iff dpkg-buildpackage starts handling the dpkg-deb calls by
itself, this bug cannot be solved. I didn't feel like marking as
wontfix because I think the request make sense, it's just that I don't
see how to implement it as things stand right now.
Thanks,
Guillem
0 new messages