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

[Roger Leigh]

On Wed, Feb 23, 2011 at 11:19:53PM +0000, Roger Leigh wrote:
> On Wed, Feb 23, 2011 at 02:02:56PM +0000, Roger Leigh wrote:
> > On Wed, Feb 23, 2011 at 12:38:34PM +0100, Philipp Kern wrote:
> > 
> > > (The backwards compatible way would be, for buildd, resolve-alternatives=true
> > > for resolver=aptitude and false and resolver=apt for the case where none's
> > > specified, i.e. previously internal.)
> > 
> > Does buildd currently assume this behaviour, i.e. does it know which
> > resolver is in use?  If so, why does it need this knowledge?  I can see
> > wanna-build finding it useful for dep-wait determination.  In fact,
> > we could get buildd to use sbuild to test if the dependencies are
> > resolvable using the build chroot without installing anything, so that
> > the resolver logic is contained in just one place.  If it would be
> > helpful, we can allow selection on the command line, so buildd can
> > force use of a particular resolver.
> 
> Sorry, being dumb here.  We do, of course, already do just this.
> 
> I can certainly alter the default resolve-alternatives behaviour from
> false to true if aptitude is in use.

This behaviour is now implemented (and documented) on git master.

internal and apt: do not resolve alternatives by default (pick first)
aptitude: resolve alternatives by default

For all these cases, the default may be overridden by setting
$resolve_alternatives.


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/20110224/4a6256f7/attachment.pgp>