Use python3 interpreter in your path instead of hardcoding /bin/python3

[dannf]

On Debian-based systems, python3 is in /usr/bin.

Signed-off-by: dann frazier dann.frazier@canonical.com

[lersek]

@encukou can you please advise if the proposed shebang (#!/usr/bin/env python3) is aligned with the python invocation rules in Fedora and RHEL? Thank you.

[encukou]

The proposed #!/usr/bin/env python3 is the best choice here.

---

In Fedora/RHEL, you'll get the most robust behavior with %{__python3}, a RPM macro. That is the system Python, regardless of the user's $PATH or virtual environment.
In Fedora, the %py3_shebang_fix macro can switch the shebang(s) for you. The macro is not in RHEL yet, so write it out as /usr/bin/pathfix.py -pni %{__python3} FILE...

[lersek]

@encukou thank you for the help!

I've now reviewed the edk2 package's SPEC file in RHEL8, where this python script is primarily meant to be invoked (down-stream), in the Brew build root. I now remember that we've already been careful enough to invoke the script from the edk2 spec file regardless of the shebang -- because this is what we have in RHEL8:

%{__python3} ovmf-vars-generator --verbose --verbose \
...

In Fedora, we have:

python3 qemu-ovmf-secureboot-%{qosb_version}/ovmf-vars-generator \
...

So the edk2 spec file in RHEL8 already uses the best possible approach. And the Fedora one, while it could be improved, is nonetheless independent of the script's own shebang.

Thus, given

• your confirmation that the proposed change is the best for upstream, and

• our already ensured downstream independence of the upstream shebang,

I'm going to approve this PR (as soon as I can figure out how to do that on this "modern" UI called "github").

Thanks!

[lersek]

Reviewed-by: Laszlo Ersek lersek@redhat.com

per above discussion.

[lersek]

@dannf I have zero clue why this PR is stuck in DCO Expected — Waiting for status to be reported state. I don't know what's missing, sorry.

[lersek]

@dannf ... because your commit message does carry your S-o-b.

[dannf]

@dannf ... because your commit message does carry your S-o-b.

Weird - it does have my S-o-b - and it is using an email address attached to my github account.