[buildd-tools-devel] testers wanted: sbuild and build-dependencies

[Roger Leigh]

On Wed, Nov 10, 2010 at 05:17:30PM -0500, Andres Mejia wrote:
> On Wed, Nov 10, 2010 at 2:57 PM, Goswin von Brederlow <goswin-v-b at web.de> wrote:
> > Roger Leigh <rleigh at codelibre.net> writes:
> >
> >> On Wed, Nov 10, 2010 at 01:00:29PM +0100, Goswin von Brederlow wrote:
> >>> Roger Leigh <rleigh at debian.org> writes:
> >>
> >> The existing approach to determinism is not to support alternatives
> >> at all, which is clearly not ideal.  While I don't think we should
> >> be encouraging the use of alternative build-deps, this is one of the
> >> most commonly reported bugs in sbuild--there are valid use cases for
> >> them.
> >
> > Actually alternatives are supported. Most notably in A [i386] | B
> > [!i386]. Sbuild fixates on the first alternative that should be
> > installable. That makes it 100% perdictable to the uploader which
> > package he gets.
> 
> This use of alternatives will fail on non-i386 machines using sbuild's
> internal build-dep resolver. It will succeed using apt or aptitude
> however.
> 
> Here's an example for anyone willing to try. It doesn't matter if the
> architecture restrictions are there or not.
> Build-Depends: linux-headers-2.6-i386 [i386] | linux-headers [!i386]

This is, AFAICT, working exactly as intended.
It's correctly picking the "linux-headers" alternative.  It then
fails because linux-headers is a virtual package, and the internal
resolver won't resolve virtual packages (where the apt and aptitude
resolvers will) by default.

D: Running command: /usr/bin/schroot -d / -c sid-amd64-sbuild-b7bb4e56-286d-470f
-870d-0673d257e7db --run-session -q -u root -p -- /usr/bin/apt-get --purge -o DP
kg::Options::=--force-confold -o DPkg::Options::=--refuse-remove-essential -q --
no-install-recommends -y install linux-headers
Reading package lists...
Building dependency tree...
Reading state information...
E: Package 'linux-headers' has no installation candidate
Package linux-headers is a virtual package provided by:
apt-get failed.
Package installation failed

If you set $enable_virtual=1, it will attempt to deterministically
resolve the dependency and it will then succeed:

D: Running command: /usr/bin/schroot -d / -c sid-amd64-sbuild-ed94fbb6-5775-4598-8237-e965218bbc94 --run-session -q -u root -p -- /usr/bin/apt-get --purge -o DPkg::Options::=--force-confold -o DPkg::Options::=--refuse-remove-essential -q --no-install-recommends -s install linux-headers-2.6-amd64
Reading package lists...
Building dependency tree...
Reading state information...
The following extra packages will be installed:
  cpp-4.3 gcc-4.3 gcc-4.3-base linux-headers-2.6.32-5-amd64
  linux-headers-2.6.32-5-common linux-kbuild-2.6.32
Suggested packages:
  gcc-4.3-locales gcc-4.3-multilib libmudflap0-4.3-dev gcc-4.3-doc libgcc1-dbg
  libgomp1-dbg libmudflap0-dbg
The following NEW packages will be installed:
  cpp-4.3 gcc-4.3 gcc-4.3-base linux-headers-2.6-amd64
  linux-headers-2.6.32-5-amd64 linux-headers-2.6.32-5-common
  linux-kbuild-2.6.32

So I don't think we need to worry too much about this specific case;
it's merely highlighting how deficient the internal resolver is!


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20101113/eeb3123c/attachment.pgp>