Preinstalled Build-Depends not properly detected

[William Grant]

See http://launchpadlibrarian.net/11049610/buildlog_ubuntu-hardy-i386.libmail-box-perl_2.078-1_FAILEDTOBUILD.txt.gz for example. We get this odd line:
 libtest-harness-perl: already installed (=*=PROVIDED=*= >= 3 is satisfied)

The build then fails like so:
 dpkg-checkbuilddeps: Unmet build dependencies: libtest-harness-perl (>= 3)

dpkg doesn't support versioned Provides, does it? Is that what it means by =*=PROVIDED=*=?

[Marco Rodrigues (gothicx)]

There is another bug related to this problem. Bug #111800

[Scott Kitterman (kitterman)]

I'm not 100% sure this patch is what we want (so I didn't link to the bug), but this looks promising (thanks to siretart on ubuntu-devel):

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456934

[Adam Conrad (adconrad)]

The patch isn't what we want, but never fear, I have it fixed locally, and the buildds will be updated today with the new code.

[Adam Conrad (adconrad)]

This is fixed in launchpad-buildd version 40, which I've just rolled out to the entire buildd farm, primary and PPA.

[Martin Pitt (pitti)]

Closing sbuild task.

[Scott Kitterman (kitterman)]

This problem still affects the version of sbuild released by Ubuntu. I realize the Soyuz version has been heavily forked, but in the interests of having sbuild in Ubuntu react similarly to Soyuz, I believe it would be useful to make a similar change in the Ubuntu sbuild, so I'm re-opening the task. At least on Ubuntu developer has expressed an interest in trying to fix this during the Hardy cycle, so I think closing it would be premature.

[Adam Conrad (adconrad)]

Fixed in sbuild_0.57.0-1ubuntu1. This turned out to be easier to fix in the packaged version than the buildd version, so it was a no-brainer to do an upload and get this finally closed.

[Emmet Hikory (persia)]

Unfortunately this doesn't resolve the test case I was given for verification. Testing a build of libmail-box-perl 2.078-1 against hardy with 0.57.0-1ubuntu1 results in FTBFS due to an insufficient version of libscalar-list-utils-perl. I've attached a buildlog for reference.

I've not reopened the bug, as I'm not sure whether this new build failure is a result of this bug, or an exposure of some other interaction between the distributed sbuild, the current state of the archive, and this particular package.