qa.sh: treat python and python[23] as an invalid shebangs

[AMDmi3]

Summary

USES=python leads to dependency on specific version of python (e.g.
python2.7) which provides interpreter bin/python2.7. Ports should
use that in shebangs, and not python2 or python which may be (or not)
installed by python metaports. In case of corresponding metaport not
installed, scripts which use e.g. '/usr/local/bin/python' or
'/usr/bin/env python3' become broken.

To fix ports with such problems, add correspondings checks to qa.sh

[mat]

Adding Python here, they should have something to say about this.

[mat]

As for the portmgr role, it looks good.

Waiting for Python people to say something.

[sunpoet]

LGTM.

[dbn]

I think this change is (possibly) incorrect when USES=python:2 (i.e. when depending on the meta-port):

make -f /usr/ports/Mk/bsd.port.mk USES=python:2 -V RUN_DEPENDS
/usr/local/bin/python2.7:lang/python27 python2:lang/python2

Given that the meta-port is listed as a dependency I don't see any issue with having a shebang to the metaport. I would even go so far and say python.mk shouldn't be adding a dependency to the python27 port (and defining many variables) when in "meta" mode.

[AMDmi3]

Ok, I'm committing more relaxed version of this which allows python[23] in shebangs.

[sunpoet]

I'm sorry to reopen it but combining D8923 and D9332 cause the problem with Q/A tests.

${LOCALBASE}/bin/{bash,perl,php,ruby} are all valid shebangs for Q/A tests regardless of their existence.
But D9332 removes the possibility for python. (${LOCLABASE}/bin/python is invalid now)
As a result, D8923 and D9332 blocked poudriere build of python-disabled ports shipped with sample python scripts.

Take www/nghttp2 for example.
It ships with a python script (fetch-ocsp-response) that will be installed in DATADIR.
However, there is no USES=python in Makefile.
Being a committer, I'd like to enable Q/A tests to find out potential problems but I have to manually disable it here.

It does not sound reasonable to add python at build time just for fixing shabang.
@miwi did some commits in this way, including lang/gcc* (by adding JAVA_USES=python:build) and net/rubygem-amq-protocol.
And @adamw chose another way to fix editors/vim by removing the shebang.
Furthermore, since python is not registered as a dependency, it can be removed or updated at any time.
The shebang is still invalid.
For example, one could upgrade from python 3.5 to 3.6, therefore ${LOCALBASE}/bin/python3.5 disappears.

Please revert D9332 temporarily and update the shebang check.
I suggest to apply this restriction (D9332) only for ports with python support.
Please let me know if you have a better solution for the case I mentioned.

Thanks!

PS: I do not why I got redirected to reviews3.freebsd.org before and did not post here correctly.

[miwi]

In D9332#215661, @sunpoet wrote:

For example, one could upgrade from python 3.5 to 3.6, therefore ${LOCALBASE}/bin/python3.5 disappears.

No python3 is not effected because python3* use "/usr/bin/env python3" as identifier, the problem is here unversioned python identifier, so the script is technically correct,
To fix it with python:build is no harm and actually the correct way.

[mat]

The invalid bin/python thing should be limited to when USES=python, because otherwise, PYTHON_CMD is bin/python.

[AMDmi3]

It does not sound reasonable to add python at build time just for fixing shabang

You don't really need python at build time to fix shebang, but the port may need it at runtime if it installs scripts with python shebang, and it is reasonable to add the dependency in this case, and the fact that some of these cases are detected is actually a positive side effect of this patch.

Regarding nghttp2, I insist that it needs USES=python. It seems to me that the only case where bin/python shebang is acceptable is a script in EXAMPLESDIR, and only given that it works with both python versions. It nghttp2 case it is a script it ${DATADIR}, a something which looks like it may be called by an application at any time, thus it needs to be executable, thus it needs both correct shebang and a dependency on an interpreter. If it's not frequently used and python dependency seems like an overkill, maintainer may consider OPTIONizing it.

For now I have a fix to allow bin/python without USES=python, but I'd prefer not to lose a capability of detecting ports which lack USES=python, and instead maybe ignore bin/python only in EXAMPLESDIR.

[AMDmi3]

Superseded by https://reviews.freebsd.org/D13571