Bug#787093: autopkgtest: dpkg-deb chokes with build profiles in Build-Depends:

[Johannes Schauer]

Hi,

Quoting Antonio Terceiro (2015-05-29 12:42:44)
> On Fri, May 29, 2015 at 02:52:10AM +0200, Guillem Jover wrote:
> > If this is indeed parsing Build-Depends, you probably also want “build_dep
> > => 1” there.
> In a part of the time, that code will be parsing Build-Depends that will be
> turned into Depends: of a fake package that is installed to pull in test
> dependencies. In that case, besides build_dep, is that anything else we need
> to pass to be sure that the end result is compatible with Depends: ?

you can see how sbuild does it which also parses Build-Depends to then create a
dummy binary package to install later from them:

http://sources.debian.net/src/sbuild/0.65.2-1/lib/Sbuild/ResolverBase.pm/#L827

Turning build-depends into a binary package seem to be a common pattern not
only shared by autopkgtest and sbuild but is also used by pbuilder or
mk-build-deps. It would be great if there was a common library doing this but
maybe the slightly different requirements of each software taking this approach
as well as the different programming languages used make this tricky.

On the other hand, I think all this software mainly does it that way because
apt in unstable cannot yet be given a .dsc or unpacked debian/control and then
satisfy the build dependencies from it. So everybody using apt to satisfy build
dependencies of a local package first creates a dummy package from these build
dependencies and only then passes it to apt.  Maybe all the software using this
approach can drop it once apt from experimental moves to unstable because that
one can do `apt-get build-dep foo.dsc`.

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/autopkgtest-devel/attachments/20150529/3f9566b5/attachment.sig>