[buildd-tools-devel] re buildd's resolver and package's build deps

[Roger Leigh]

On Wed, Mar 16, 2011 at 01:07:19AM +0100, Goswin von Brederlow wrote:
> Roger Leigh <rleigh at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20110316/7206c8a9/attachment.pgp>