Control: severity -1 important
Control: tags -1 + confirmed
Hi, Anthony,
thanks for the report!
On 17 Jul 2020, Anthony Fok wrote:
>I ran into the following error while packaging the latest version of
>hugo package:
>
> dh_bash-completion: error: Cannot resolve variable
> "${BASH_COMP_DEBUG_FILE}" in debian/hugo.bash-completion (line 5)
>
>where debian/hugo.bash-completion is a proper completion snippet.
How to reproduce (note to myself):
On a system with debhelper >= 13:
$ git clone https://salsa.debian.org/go-team/packages/hugo.git
$ cd hugo
# apt install hugo
$ hugo gen autocomplete --completionfile=debian/hugo.bash-completion
$ dh_bash-completion
dh_bash-completion: error: Cannot resolve variable "${BASH_COMP_DEBUG_FILE}"
in debian/hugo.bash-completion (line 5)
>It turns out that the error was triggered when I bumped
>"debhelper-compat (= 12)" to "debhelper-compat (= 13)" in debian/control.
>
>This is a behavioural change in debhelper v13. From debhelper(7):
>
> - Many dh_* tools now support limited variable expansion via
> the ${foo} syntax. In many cases, this can be used to
> reference paths that contain either spaces or
> dpkg-architecture(1) values. While this can reduce the
> need for dh-exec(1) in some cases, it is not a replacement
> dh-exec(1) in general. If you need filtering, renaming,
> etc., the package will still need dh-exec(1).
>
> Please see "Substitutions in debhelper config files" for
> syntax and available substitution variables. To dh_* tool
> writers, substitution expansion occurs as a part of the
> filearray and filedoublearray functions.
>
>dh_bash-completion currently uses filedoublearray() to detect if
>debian/package.bash-completion is a list of files or not.
>While it has worked well in the past, it has now become a lot more
>flakey and error-prone as debhelper v13+ now always attempt
>such variable substitution.
Thanks for the analysis. :)
>While one could try to work around the issue by changing
>"${foo}" to "$foo" in the proper completion snippet,
>quoting variables with curly braces like ${foo} is nonetheless
>perfectly valid bash syntax, and it is often unavoidable
>in cases such as "${foo}bar" or "${foo}_bar".
I agree, it would be terrible to forbid scripts from using it.
>Perhaps there are better ways to distinguish whether
>debian/package.bash-completion is a file list or proper snippet
>than sending it to filedoublearray() and see if it fails or not?
I really suck at perl programming, but, as far as I can tell, that's
not the only reason to call filedoublearray(). dh_bash-completion uses
the *output* of filedoublearray(), not its return code, to detect
whether the file is a proper snippet. However, since debhelper 13,
filedoublearray() fails during variable expansion (if we track the
failure down, it happens in _variable_substitution()), so
dh_bash-completion doesn't actually get a chance to check if the file
is a proper snippet or a list of files.
I'll try and find a solution for this, but I might need help from perl
experts. :)
Cheers,
Gabriel
