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 <firstname.lastname@example.org> wrote: > > Roger Leigh <email@example.com> writes: > > > >> On Wed, Nov 10, 2010 at 01:00:29PM +0100, Goswin von Brederlow wrote: > >>> Roger Leigh <firstname.lastname@example.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.
Description: Digital signature