Package: debhelper Version: 7.4.3 Severity: normal Hello,
This is a follow up to my patch from [1]. Since the patch does not really deal with argument parsing, just with consistent and accurate debhelper command and its arguments printing, I'm opening a new bug to track this. Since options to debhelper commands can be passed via DH_INTERNAL_OPTIONS, DH_OPTIONS and command line, the first two are typically not visible in the logs. Invisibility of DH_INTERNAL_OPTIONS is especially bad since dh puts "black magic" in there. To better expose this, dh should print a final command line of dh_* commands as they are executed. My previous patch proposed dh_* to print their command line by themselves. Now I attach a proof of concept implementation (sequencer, aka dh, and dh_command) of the following scheme: 1) Sequencer creates a pipe, exports its FDs in DH_BATCH_MODE environment variable and forks into two processes. The first process listens on the pipe for commands from dh_* commands and handles dh_* command line printing. The 2nd process executes commands (like current dh does now). 2) As dh executes dh_command, the latter parses its command line and determines which options are valid and which are not (code in the attached dh_command script). Real dh command would process DH_INTERNAL_OPTIONS, DH_OPTIONS and @ARGV and merge the results into single command line. Finally, dh_command sends its full and *valid* command line to dh via open pipe. 3) dh prints that command line and sends back a signal to dh_command to start doing real work. 4) dh_command receives a start signal and continues as usual. This way, dh_command does not have to print its own command line which was an ugly disadvantage of my previous patch. All command line printing is handled by sequencer itself. The attached proof of concept scripts are rather small, easy to edit and play with, and good for demonstrating the behaviour of this scheme. I will eventually port them to dh/Dh_Getopt if you agree on the concept and/or output format. So quick how-to: $ tar zxf dh-output.tar.gz $ cd dh-output $ debian/rules sequencer --> dh_command --> dh_command --> dh_command --> dh_command --try=4 --> dh_command --> dh_command --> dh_command --> dh_command --> make -f debian/rules override_dh_command make[1]: Entering directory `/home/modax/test/dh-output' dh_command --bar --> dh_command --bar make[1]: Leaving directory `/home/modax/test/dh-output' --> dh_command --try=10 --foo --> dh_command --try=11 --bar --> dh_command --try=12 --> dh_command --> dh_command --> dh_command --> dh_command --> dh_command --> make -f debian/rules override_dh_command make[1]: Entering directory `/home/modax/test/dh-output' dh_command --try=18 --bar --> dh_command make[1]: Leaving directory `/home/modax/test/dh-output' --> dh_command --> dh_command --> dh_command --> dh_command --foo --> dh_command --> dh_command --try=24 --> dh_command --bar --> dh_command --> make -f debian/rules override_dh_command make[1]: Entering directory `/home/modax/test/dh-output' dh_command --try=27 --> dh_command make[1]: Leaving directory `/home/modax/test/dh-output' --> dh_command --> dh_command --try=29 --> dh_command As you see, sequencer simulates dh overrides too to be as near real world output as possible. Such format looks rather well to me... 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541773#10 -- Modestas Vainius <modes...@vainius.eu>
dh-output.tar.gz
Description: application/compressed-tar
signature.asc
Description: This is a digitally signed message part.
