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
