Control: tag -1 + patch Hi,
Quoting Johannes Schauer (2016-01-04 13:39:25) > Quoting Colin Watson (2016-01-04 13:21:47) > > On Sun, Jan 03, 2016 at 09:40:28PM +0100, Johannes Schauer wrote: > > > What prevents a dummy package being used instead as it is done in the > > > native case? > > > > See https://bugs.debian.org/697298. Using "apt-get install" rather than > > "apt-get build-dep" fails to handle ":native" qualifiers on > > build-dependencies. Those are disallowed in Depends but allowed in > > Build-Depends, so mangling Build-Depends into Depends is a bad idea in cases > > where these particular semantics are important. > > the :native qualifier has been taken care of for native builds with the patch > I > submitted for bug #777216 > > > Please don't get rid of this change - it's useful. > > With that patch in place, why is it still useful? > > > The native and cross paths differ only because I was being conservative > > about > > changing things. If you're working on this anyway, I'd prefer us to switch > > to the build-dep approach across the board. I have a to-do note in my local > > copy to check whether both --resolve-alternatives and > > --no-resolve-alternatives work properly with that, though. > > What I would like to switch to would be for apt to use "apt-get build-dep > foo.dsc" which would make the internal dummy repo unncessary. Unfortunately > sbuild can only switch to this approach once apt supporting this is in > old-old-stable. Until then it has to continue using dummy packages. > > With that in mind: what is the advantage of using "apt-get build-dep" over > "apt-get install"? The latter method is tried and tested with native builds. > The former method is less tested as it's only used for cross builds. Why > switch > to the build-dep method? > > As far as multiarch is concerned, they should behave the same way anyways, no? > > As far as syntax is concerned the only difference is that the Build-Depends > field allows architecture qualifiers, build profile restrictions and the > :native qualifier. But the former two are handled by dpkg while the latter is > rewritten to :${buildarch}. > > The "apt-get install" method has the advantage that we are less dependent on > apt doing the right thing. The more we let apt *inside* the chroot handle > dependency resolution instead of libdpkg-perl at the outside creating dummy > binary packages, the less flexible we are once new dependency constructs are > introduced. > > Things like cross building and build profiles are such an example. The apt > inside the chroot needs to have no clue about build profiles because dpkg > outside the chroot already did the necessary mangling. attached patch removes 'apt-get build-dep' for cross compiling and instead relies on the existing dummy binary package system. It seems to work fine for the packages I tested. In the commit message I again summarized the situation and discussed the reasonings behind my thinking. If you think I forgot to consider something, please speak up! > > Now, regarding your problem at hand in #809730, this shouldn't get in your > > way. Even when using build-dep, sbuild should still use its dummy archive; > > the difference is merely whether it uses the Packages or Sources file it > > generates. It would be worth checking whether the Sources file is being > > generated properly. > > Right, the problem in #809730 might just be that the Sources file is generated > in a way that does not take build profiles into account. If it were, then apt > would not need to know about build profiles (so even older apt would work). Thanks! cheers, josch
From 61a3b795bb65a683bd4f747ac81c8c00427abd5e Mon Sep 17 00:00:00 2001 From: Johannes 'josch' Schauer <[email protected]> Date: Wed, 6 Jan 2016 10:10:39 +0100 Subject: [PATCH] When cross compiling, install dummy binary package instead of using 'apt-get build-dep' For unknown reasons, 'apt-get build-dep' has so far been used to install cross build dependencies. This should not be necessary because cross build dependency resolution should not be different from cross architecture binary dependency resolution as far as multiarch is concerned. Build-Depends specific constructs are taken care of either by Dpkg::Dep::deps_parse (architecture qualifiers, build profile restriction lists) or by rewriting the ':native' qualifier to the correct architecture in course of commit d4c137190 or fixing of bug #777216. It could be argued that sbuild should use 'apt-get build-dep' for all its operation including native compilation. This would mean that quite some logic could be removed from sbuild. The downside would be that this would mean that sbuild's ability to correctly resolve dependencies would increasingly depend on the apt *inside* the chroot. This apt might be quite old and not support certain dependency constructs. Examples for recently introduced constructs are the :native qualifier or build profiles. With the current setup of creating dummy binary packages to satisfy build dependencies, the apt inside the chroot does not need knowledge of either of these as sbuild (or libdpkg-perl) is used to mange build dependencies into runtime dependencies such that the apt inside the chroot does not need to concern itself with newly introduced features. This for example allows a package using build profile syntax to be compiled in a Debian Wheezy or even Squeeze chroot. If sbuild were to use 'apt-get build-dep' for dependency resolution then before compiling packages using newer syntax elements on older Debian releases, the package would have to be modified first. So in summary, with the dummy binary package system sbuild is offering the possibility that compiling new packages on older systems (for example for backports) can be done without a change to the package itself. Creating the dummy binary packages takes up a large amount of complexity within sbuild but it is complexity we can control by making new releases into unstable. We cannot control old apt releases in old Debian chroots. It would be nice if this complexity could be removed from sbuild but since this system works and has been extensively tested, it does not make sense to remove it and thus remove a feature (building new packages on older systems) from sbuild. Right now I don't see a disadvantage of the dummy package system besides the complexity it adds to sbuild. One disadvantage used to be that it requires keys to be generated but this has been solved with commit aea9a4d9 or closing of bug #801798 using apt-get's feature of [trusted=yes] in sources.list. We can revisit removing the dummy package system from sbuild once apt (>= 1.1) is in old-old-stable because that apt version allows "apt-get build-dep foo.dsc". So this feature would remove the requirement for creating a dummy repository altogether. With that feature, sbuild would not need to mangle the build dependencies at all - not even to create a dummy Sources file. --- lib/Sbuild/AptResolver.pm | 11 +---------- lib/Sbuild/AptitudeResolver.pm | 1 - lib/Sbuild/AspcudResolver.pm | 1 - lib/Sbuild/ResolverBase.pm | 5 ++--- lib/Sbuild/XaptResolver.pm | 1 - 5 files changed, 3 insertions(+), 16 deletions(-) diff --git a/lib/Sbuild/AptResolver.pm b/lib/Sbuild/AptResolver.pm index 7485cda..e476a38 100644 --- a/lib/Sbuild/AptResolver.pm +++ b/lib/Sbuild/AptResolver.pm @@ -52,7 +52,6 @@ sub new { sub install_deps { my $self = shift; my $name = shift; - my $cross = shift; my @pkgs = @_; my $status = 0; @@ -69,15 +68,7 @@ sub install_deps { # Install the dummy package my (@instd, @rmvd); $self->log("Installing build dependencies\n"); - my @apt_args = ("-yf", \@instd, \@rmvd); - if ($cross) { - # Cross-building: 'apt-get build-dep' knows how to get the multiarch - # details right. - push @apt_args, - '-a' . $self->get('Host Arch'), 'build-dep', $dummy_pkg_name; - } else { - push @apt_args, 'install', $dummy_pkg_name; - } + my @apt_args = ("-yf", \@instd, \@rmvd, 'install', $dummy_pkg_name); if (!$self->run_apt(@apt_args)) { $self->log("Package installation failed\n"); diff --git a/lib/Sbuild/AptitudeResolver.pm b/lib/Sbuild/AptitudeResolver.pm index 1c0c53b..69deffe 100644 --- a/lib/Sbuild/AptitudeResolver.pm +++ b/lib/Sbuild/AptitudeResolver.pm @@ -53,7 +53,6 @@ sub new { sub install_deps { my $self = shift; my $name = shift; - my $cross = shift; my @pkgs = @_; diff --git a/lib/Sbuild/AspcudResolver.pm b/lib/Sbuild/AspcudResolver.pm index e9ea0a1..70a1724 100644 --- a/lib/Sbuild/AspcudResolver.pm +++ b/lib/Sbuild/AspcudResolver.pm @@ -51,7 +51,6 @@ sub new { sub install_deps { my $self = shift; my $name = shift; - my $cross = shift; my @pkgs = @_; my $status = 0; diff --git a/lib/Sbuild/ResolverBase.pm b/lib/Sbuild/ResolverBase.pm index 86c831e..5637b1d 100644 --- a/lib/Sbuild/ResolverBase.pm +++ b/lib/Sbuild/ResolverBase.pm @@ -416,15 +416,14 @@ sub install_core_deps { my $self = shift; my $name = shift; - return $self->install_deps($name, 0, @_); + return $self->install_deps($name, @_); } sub install_main_deps { my $self = shift; my $name = shift; - my $cross = $self->get('Host Arch') ne $self->get('Build Arch'); - return $self->install_deps($name, $cross, @_); + return $self->install_deps($name, @_); } sub uninstall_deps { diff --git a/lib/Sbuild/XaptResolver.pm b/lib/Sbuild/XaptResolver.pm index a3f995c..139c202 100644 --- a/lib/Sbuild/XaptResolver.pm +++ b/lib/Sbuild/XaptResolver.pm @@ -52,7 +52,6 @@ sub new { sub install_deps { my $self = shift; my $name = shift; - my $cross = shift; my @pkgs = @_; my $status = 0; -- 2.5.1
signature.asc
Description: signature
