On Wed, Mar 16, 2011 at 01:07:19AM +0100, Goswin von Brederlow wrote: > Roger Leigh <rle...@codelibre.net> writes: > > > On Mon, Feb 28, 2011 at 03:36:47PM +0100, Wouter Verhelst wrote: > >> On Tue, Feb 22, 2011 at 05:08:18PM +0000, Roger Leigh wrote: > >> > On Mon, Feb 21, 2011 at 07:42:32PM -0600, Raphael Geissert wrote: > >> > > I disagree here. > >> > > Alternatives in build-* relationships *are* mentioned by policy. In > >> > > fact, > >> > > there's even an example in section 7.1. > >> > > >> > This is correct. I was thinking about drafting a patch for Policy > >> > about this. Current Policy defines the allowed syntax for > >> > Build-Depends. It does not however, make any mention of existing > >> > conventions and best practices, which I feel should be addressed. > >> > > >> > The current "internal" build dependency resolver does not make > >> > any use of the alternative dependencies. It always picks the first. > >> > >> It was my understanding that there are some corner cases in which it > >> would select the second: > >> > >> - where one build-dependency (indirectly) depends on a secondly-listed > >> alternative, it could install the second. > >> - sbuild will not worry about installing the first alternative if the > >> second has already been installed. > >> > >> but I might be mistaken about one or both of the above. > > > > I'm not totally sure either, to be honest. The internal resolver code > > is horrible. It looks like it still has relics of manual source-deps > > entangled in there as well (but I don't dare to touch it since it will > > probably break horribly if I delete it). The alternatives processing > > is in Sbuild::InternalResolver::parse_one_srcdep and > > filter_dependencies, and it looks like it could well be OK with second > > alternatives if installed. > > You are not mistaken. At least in the past the resolver would first > remove all packages from Build-Depends that are already installed. Only > those part of Build-Depends that are unfullfilled are installed using > the first alternative after arch reduction.
OK. I think this is the only known discrepancy between the two resolvers. Given that we now routinely build using minimal clean (cloned) chroots, they will behave identically in practice because non-first alternatives will not be present in the clean chroot, so this behaviour in the internal resolver will not be exercised in practice. I certainly saw no evidence of it during my whole-archive rebuild. 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.
signature.asc
Description: Digital signature
