[buildd-tools-devel] Bug#633777: Bug#633777: sbuild: virtual dependency resolver broken?

[Roger Leigh]

On Wed, Jul 13, 2011 at 06:28:53PM +0200, Thibaut VARENE wrote:
> On Wed, Jul 13, 2011 at 6:05 PM, Roger Leigh <rleigh at codelibre.net> wrote:
> > On Wed, Jul 13, 2011 at 05:38:16PM +0200, Thibaut VARENE wrote:
> 
> >> In any case, the fact is it breaks the virtual resolver for packages with multiple providers (i've tested that when there's only one provider, there is no problem. I suppose apt-get does
> >> the right thing then).
> >
> > There are two areas of brokeness here: apt-get and sbuild itself.
> > While apt-get is definitely misbehaving here, sbuild's "internal"
> > resolver is also absolutely awful at working with virtual packages.
> > While we did do some refactoring when introducing the "apt" resolver,
> > it could well be that the root cause was apt-get being broken.
> > You could try using the "apt" resolver which delegates all dependency
> > resolution to apt-get.  It's the default in current unstable, and
> > can handle virtual dependencies without issues, including alternatives.
> 
> So, I tried the 'aptitude' resolver, since I couldn't find any mention
> of a 'apt' resolver in the source code (note by the way that as far as
> I can tell, none of this is documented anywhere ;P) using the
> following in .sbuildrc:
> $build_dep_resolver="aptitude";
> 
> And it did "fix" the issue, while installing more stuff (aptitude)
> into the chroot.

The "apt" resolver may not yet be available in stable.  It's
certainly in testing.  And this should all be documented in the
testing/unstable version in the sample sbuildrc and sbuild.conf.
Just checked the changelog and the stable version does lack it.

> > I would also suggest trying the latest sbuild/libsbuild-perl in
> > testing/unstable.  They should run without problems on squeeze by
> > design.  If the bugs are still causing problems with this version,
> > we can at least address them whereas updating the squeeze version
> > is rather more difficult.
> 
> Well, given the lack of documentation, especially on upgrade process,
> and my previous experience with generally painful upgrades from
> version to version (0.60 entirely broke backward compatibility with
> 0.58 configs), I'm not exactly thrilled by the idea... ;P

In theory, we should be completely backward compatible--we continue
to allow the use of older configuration variables in order to not
break compatibility with older formats.  If you are seeing breakage,
I would appreciate knowing what's broken, so we can fix it.

We have definitely made the config parser stricter though--it will now
error out where it would previously continue e.g. if you misnamed a
variable.  And where we have removed configuration options, you might
well be required to comment out/remove them from your configuration.
But anything that's present in old and new versions should continue to
work.  If it doesn't, I'll fix it.


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: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20110713/2ffa2c4f/attachment.pgp>