Hi! On Fri, 2026-10-30 at 20:44:01 +0900, Cheng Li wrote: > Control: tags -1 + patch
> Here is the patch series you asked for back in July; sorry for the long > delay. It is two patches on top of current main (7492eb3d9). Thanks! > Patch 1 fixes a bug I ran into while enumerating the options. The > --help output has documented -ap's long form as --sign-pause since the > long options were added in 1.18.8 (293bd243a), but the parser was > written as --sign-pausa, so the documented spelling has never been > accepted, and the accepted one has never been documented, neither in > --help nor in the man page. I did not keep the misspelling as a > deprecated alias: it was never part of the documented interface, and > -ap has always worked, so there is nothing to deprecate; --sign-pausa > now gets the usual unknown option error, which names the option. The > patch also adds the man page entry, which has been missing all along, > annotated as "Support for long option since dpkg 1.23.12", as that is > when the long option starts to actually work; please adjust if this > lands in a different release. A test asserts that the documented > spelling is accepted. Nice catch, perfect! I've merged this locally and will include in my next push. > Patch 2 is the completion itself, following the dpkg-source file on > main and the bash-completion 2.12 API, together with the packaging > bits, in the shape of 9d6fa2c83. It completes option names and, where > there is something sensible to offer, option values: build types, rules > targets, architectures, build profiles, OpenPGP backends, compression > parameters, command arguments for --root-command, --sign-command, > --check-command and --hook-*, pathname arguments, and the positional > .dsc file or source directory. The --buildinfo-id, -E and -W options > are deliberately not completed, as they are accepted but have no > effect. Ah, thanks! I had also started adding the missing completions for all commands last month, and ended up partially doing dpkg-buildpackage, in the following WIP pu/bash-completions branch from this repo, which I just rebased and pushed to: <https://git.hadrons.org/cgit/debian/dpkg/dpkg.git> But it seems some of my changes complement some of yours. So it would make sense if you adopted some of those into your patch? > One packaging note: debian/dpkg-dev.install lists the files > individually, and with debhelper compat 13 dh_missing --fail-missing is > the default, so without that line dpkg's own package build fails. Sure, it is expected that we add explicit lines for each new script, instead of using globs, so that we control when something appears or disappears (on purpose or by accident). > I tested the completion with an offline harness that drives the > function directly (26 cases, covering option names and values) against > bash-completion 2.16; make check passes in a configured tree; and a > full "dpkg-buildpackage -b" of dpkg itself succeeds, with dh_missing > quiet and lintian reporting nothing on dpkg-dev. Ah great! > Two unrelated things I noticed, both happy to turn into patches if you > want them: > > - scripts/.gitignore uses unanchored script names, so the new > completion file matches the "dpkg-buildpackage" entry and needs > git add -f; the imported dpkg-source completion has the same > property. Anchoring the entries with a leading "/" would avoid it. Right, it looks I was also bothered by this, and ended up adding negated entries (in a commit in that branch). But I think I do prefer your proposed fix better. So feel free to provide a patch for that. > - Test::Dpkg::all_shell_files does not pick up > scripts/completion/bash/, so t/shellcheck.t has never covered the > completion files, dpkg-source included. I ran shellcheck by hand > with the exclude list from t/shellcheck.t, which is how I noticed > SC1010 on the "done" hook name; patch 2 quotes it. Nice catch as well. I was curious whether the current completion files were fine, so added this locally now (with attribution), and fixed a couple of issues with the dpkg-deb completion. > I can also push the series as a branch to my Salsa fork if that is > easier to look at, and I am happy to rework anything. No worries, this is good. Thanks, Guillem
