[buildd-tools-devel] Bug#766939: wanna-build: Wanna-build considers alternatives, but buildds don't, causing futile builds

[Johannes Schauer]

Hi,

On Mon, 27 Oct 2014 08:28:25 +0100 Kurt Roeckx <kurt at roeckx.be> wrote:
> On Mon, Oct 27, 2014 at 02:27:01AM +0000, Wookey wrote:
> > My current example is openmeeg. This build-deps on libtiff4-dev |
> > libtiff-dev
> 
> We pass this to edos to check it.

the edos project ended in 2007 and the last upstream release was in 2009. The
project is now dose3 and the last edos release is in old-stable.

> But as far as I know we strip the "| libtiff-dev" part both in wanna-build
> for edos and in sbuild for apt.

Could you point me to the piece of code that does that stripping before giving
the source package to dose3? I am only familiar with the code that does the
stripping in sbuild.

Maybe you are not using libdpkg-perl to do the parsing and thus are missing
instances that use recently added syntax.

> So I really have no idea why edos thinks it's installable and apt thinks it's
> not installable and edos thinks it is.

I used the snapshot of october 20 2014 for testing:

http://snapshot.debian.org/archive/debian/20141010T042049Z/dists/sid/main/

The installation set dose-builddebcheck chooses for src:openmeeg does *not*
contain the first alternative of its build dependency on "libtiff4-dev |
libtiff-dev" but instead includes libtiff5-dev which provides libtiff-dev and
also Replaces: libtiff4-dev. As sbuild mangles the dependencies, apt does not
see the second alternative and fails as a package named or providing
libtiff4-dev is not present in the Packages file of that timestamp.

So this does exactly match wookey's initial report and suggests that the
dependencies are *not* mangled before giving them to dose3 in the same way they
are mangled by sbuild.

Dose upstream git now added the new option --dropalternatives to
dose-builddebcheck which should emulate the sbuild behaviour exactly. We might
change the name of the option before the next release though, so this is just a
heads up.

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20150605/7043b0c1/attachment.sig>