Hi, Quoting Helmut Grohne (2015-05-28 12:55:03) > On Thu, May 28, 2015 at 08:43:12AM +0200, Lucas Nussbaum wrote: > > This worked fine when I tested it locally because I use sbuild, but now > > that it is uploaded, I realize that: - pbuilder doesn't support it (which > > breaks the package on reproducible.d.n) > > pbuilder is maintained with NMUs, i.e. it's unmaintained. It had a patch > for an earlier version that gained little interest. That patch is recorded in bug #740577. I now updated that bug with a patch that makes the default aptitude resolver of pbuilder compatible with the build profile syntax in Jessie. Whoever cares about pbuilder can now test and apply that. > Also once experimental apt becomes unstable (whenever that happens), we can > easily add a new "apt-get build-dep foo.dsc" resolver to pbuilder that nicely > sidesteps this and future issues by reusing an external parser. I had a quick look at implementing this and it seems that this requires a bit more shuffling of code because right now pbuilder first installs the build dependencies and only then copies the dsc into the chroot. This order would have to be inverted together with the associated hooks. This might break some software that relies on pbuilder and hooks. > > Note that in most tools, it's not difficult to add basic "support" for it, > > because it only means ignoring build profiles entirely. No, basic support does not mean to just "ignore" the part inside the <> "brackets". Suppose the following: Build-Depends: foo <stage1> If the part inside the <> "brackets" would just be ignored, then this would mean that the source package would now build depend on "foo". So instead, the restriction formula has to be evaluated with the assumption that no profile is set. The only thing that makes adding "basic support" easier than "full support" is, that there is no need to add facilities to add more command line arguments, change function signatures and generally pass around the list of activated profiles from the front end to the dependency parser. > In my (and probably Johannes') experience, the difficult part was discovering > what needs fixing. If we were to defer using build profiles to buster, we'd > gain exactly nothing, because we won't figure out what breaks. We'd ask the > same question once stretch is released for buster. Let's not go down that > road. Another example is Antonios email in this thread - I had no idea that autopkgtest would break so it never made it to the list and I never wrote a patch. Only uploading of more packages using the syntax can help find more of these instances that need fixing. Thanks! cheers, josch
Attachment:
signature.asc
Description: signature