Re: Change the python interpretor to use /usr/bin/env python3

[Bruno Haible]

Bernhard Voelker wrote:
> FWIW there are discussions [1] in the opposite direction, i.e., to avoid
> /usr/bin/env in the shebang where possible.  E.g. in openSUSE there is a
> check for RPM builds which leads to:
> 
>   pyrenamer.noarch: E: env-script-interpreter (Badness: 9) /usr/bin/pyrenamer 
> /usr/bin/env python
>   This script uses 'env' as an interpreter. For the rpm runtime dependency
>   detection to work, the shebang #!/usr/bin/env python  needs to be patched 
> into
>   #!/usr/bin/python  otherwise the package dependency generator merely adds a
>   dependency on /usr/bin/env rather than the actual interpreter 
> /usr/bin/python.
>   Alternatively, if the file should not be executed, then ensure that it is 
> not
>   marked as executable or don't install it in a path that is reserved for
>   executables.

It would make sense for the "rpm runtime dependency detection" to recognize
the /usr/bin/env case as well. In fact, there's already a TODO item in the
source code about this [2].

Additionally, this discussion what rpm does or does not do is not related to
gnulib. What rpm does has an impact on the difference between a tarball/source
code meant to be installed by users _from_source_ and a package/binaries meant
to be installed _from_a_distro's_repositories_. This is what rpm is about.

Whereas gnulib is always installed from a tarball/source code. gnulib does not
have distro-package maintainers.

Therefore, in gnulib, the most general solution is the best one:
  #!/usr/bin/env python
or
  #!/usr/bin/env python3

The user can then create a symlink as they wish:
  ln -s /usr/bin/python3 $HOME/bin/python
Or rely on /etc/alternatives/...

Bruno

[2] 
https://github.com/rpm-software-management/rpm/blob/master/scripts/script.req