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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
