On Thu, May 28, 2015 at 08:43:12AM +0200, Lucas Nussbaum wrote: > It seems the early support in dpkg confused me into thinking that it was fully > supported in stretch. > > So, the question is: should we wait until stretch is released to use build > profiles, to give time to all infrastructure tools to support them, or should > we fix our infrastructure using backports? > > I don't mind reverting my changes, of course. But it's probably worth a > debian-devel@ discussion first. > > Note that in most tools, it's not difficult to add basic "support" for it, > because it only means ignoring build profiles entirely.
I mostly agree with Helmut, in that we need to push this otherwise it is never going to happen. I was trying to upload a new version of gem2deb myself, and just noted that the build profiles in the gem2deb Build-Depends also break autopkgtest. As a dependency resolver, autopkgtest generates a fake package using the test dependencies of the package under test, which can include its build-dependencies (with build profiles, if any). This fake package is then built with dpkg-deb, its binary unpacked into the testbed, and then `apt-get install -f` is called to fix the world. At the moment what happens is that dpkg-deb blows up at the build profiles syntax, and autopkgtest aborts. I understand that it does not make sense for the build profiles syntax to be supported in Depends:, so I am writing a patch to filter out the build profiles in autopkgtest. -- Antonio Terceiro <terce...@debian.org>
signature.asc
Description: Digital signature
