The rationale behind this was that it should just compile with Qt > 4.4 and take
the newest version available. But yes with Qt packaging in different names
between 4 and 5 etc. I can see that this can be problematic.

With: 08ec9556c8a384ea7bb5d42d3f6aab6c2f6a8786 I've added an option
"disable-pinentry-qt5" to explicitly disable looking for qt5.

Does this solve your problem?

Thank you, that is exactly the kind of mechanism I was looking for. I'll give it
a try to packaging over the next few days.

"+ have_qt5_libs = no;" result in command not found issues in configure so I
changed this to "+ have_qt5_libs="no";".

I've done some preliminary packaging tests and things seems to be working as
expected, will give it some more local testing before pushing it onto users in
testing

I've fixed the variable assignment with rev. e9d063e
Sorry. Worked for me on debian jessie with dash.

Thanks, but I'm afraid that's not sufficient; the issue of the whitespace after
have_qt5_libs still exists after that commit for bash.

See the following test case: $ cat ./test.sh
#!/bin/bash
have_qt5_libs="no";
echo ${have_qt5_libs}

have_qt5_libs2 = "no";
echo ${have_qt5_libs2}

$ ./test.sh
no
./test.sh: line 5: have_qt5_libs2: command not found

The good news is that besides this buglet I've now pushed the updated revision
to our testing repository and have yet to get any bug reports. The patch I've
pushed is
https://gitweb.gentoo.org/repo/gentoo.git/tree/app-crypt/pinentry/files/pinentry-0.9.6-add-disable-pinentry-qt5-option.patch#n38
which doesn't experience this issue.

Right. Hopefully fixed with 48ab8cd

I wonder why this worked for me. If I try to run your testcase it fails with
bash / dash / zsh.

looks good to me