[buildd-tools-devel] Bug#665021: nuitka: FTBFS: unsatisfiable build-dependencies: base-files (< 6.0) but 6.7 is to be installed

[Lucas Nussbaum]

On 23/03/12 at 10:19 +0100, Kay Hayen wrote:
> 
> Hello Lucas,
> 
> >>As to deterministic, are you implying that the choice is not made in
> >>a deterministic way? It probably is just that somebody or something
> >>hates it when not all choices are valid.
> >
> >If you use alternative build-deps, two builds of the same package at
> >the same time might produce different binary packages (and it could
> >happen that the i386 and amd64 packages are built against different
> >dependencies, for example). That is not something desirable.
> 
> As you can imagine, I would prefer to use optional build-deps and
> use the alternative one only as a stop-gap.
> 
> The selected version of base-files is carefully selected to achieve
> the desired effect, i.e. no Debian this package builds on has both,
> so there cannot be indeterminism at all.
> 
> Yet, I would also like to understand (feel free to ignore my desire
> to learn, and notice how it cannot apply to the Nuitka package as
> state above): Why (in a chroot, mind you) if both alternatives are
> available, a random one would be picked. Is there really a
> "random()" call in dpkg.
> 
> Or was this just a general statement relating to non-chroot builds,
> where it clearly will be true that if the second one is already
> installed, it will change the result.

In the general case, if you Build-Depends on A | B, sbuild or pbuilder
or whatever is free to choose to install either A or B, which could
generate different builds. So what sbuild does is that it filters
build-dependencies so that A is always the one installed.

In your case, it generates a build-dep that is unsatisfiable. But doing
enough analysis on sbuild's side to determine that A is not installable,
so B should be used instead, doesn't sound something doable.

So it's much easier to fix that problem in your package, for example by
build-depending on B | A.

Lucas