On Tue, Dec 24, 2013 at 01:18:46AM +0100, Guillem Jover wrote: > On Mon, 2013-12-23 at 11:36:19 +0100, Guido Günther wrote: [..snip..] > > The current unstructured output of dpkg-buildpackage leaves us only with > > parsing the logs and looking at the exit status. Since the exit status > > seems to be that of the invoked command mostly (except for > > dpkg-checkbuilddeps) we can't infere what failed. > > > > So there are two parts: > > > > 1.) progress report (which step are we currently at) > > 2.) error report (which step failed and why) > > > > While 2.) can be fixed via more detailed exit codes 1.) can't. > > Ok, I'll take a look at this while I'm finishing up the > dpkg-buildpackage rework for 1.17.6, as at least the first is trivial > now that the required foundation for the shell hooks is there.
Great! > > > For example for 1.17.6 I'm adding hooks support, which can be useful > > > for wrappers. > > > > Hooks are nice and can be useful but they can also be confusing: > > > > gbp (hooks) -> pbuilder (hooks) -> dpkg-buildpackage (hooks) > > > > If dpkg-buildpackage doesn't want to suck in the functionality of the > > other two a nice way to propagate information like progress, errors, > > build results up the chain would be really nice. > > Just to be clear, I was not suggesting to use (shell) hooks as a > replacement for something like a --status-fd, that might end up being > very cumbersome, just an example of things that a frontend/wrapper > might need that are only possible if supported by the tool. > > OTOH something else that I could envision are perl hooks, possibly in > addition to the shell ones, so that other tools could be implemented > as modules extending dpkg-buildpackage functionality, instead of > programs wrapping it. And one could, for example, do something like: > > $ dpkg-buildpackage --modules schroot,git > > And get the Dpkg::*::Schroot.pm and Dpkg::*::Git.pm modules loaded and > specific hooks run with enough config and information, at the key stage > points. I see. This would move dpkg-buildpackage up the stack and turn it into kind of a frontend by itself. This might work out o.k. although I'm quiet happy with dpkg-buildpackage being a bit minimalistic (and therefore very reliable) like it's atm. I wonder if this could hinder dpkg-buildpackage's development speed since we'd have to care about API stability to lots of lots of modules as well? > > > > This report is triggered by #732678 where gbp failed to find the > > > > generated changes file for a architecture independent package build > > > > since it didn't look at the options passed to dpkg-buildpackage until > > > > recently. > > > > > > For the problem described in the bug report, I think a better way to > > > solve this is to run lintian directly from dpkg-buildpackage, which > > > will be possible with dpkg 1.17.6, by using the new check-command > > > support. See the following commit for further details: > > > > > > > > > <http://anonscm.debian.org/gitweb/?p=dpkg/dpkg.git;a=commitdiff;h=1cef5694> > > > > > > Or do you need the .changes file for something else? > > > > (Rahpael pointed this out already) If one may want the build > > environment to be as minimalistic as possible and not want to have > > lintian or other verifiers in there. We can also use the changes file to > > find out about the other build artifacts to upload them to a temp > > repository or some such. So invoking lintian is not the only usage and > > Right. > > > I'd rather not see every usage scenario crammed into dpkg-buildpackage > > itself. > > Oh, me neither (at least not directly), I was just trying to gather what > you had in mind to see how that could be best placed in dpkg-buildpackage > (or other tools). Thank you for your feedback! Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
