On Thu, 2020-01-09 at 09:58 +0000, Joachim Wagner wrote:
will /usr/bin/python then point to python3?
Reason: bluez has test scripts that have a #!/usr/bin/python shebang, but work just fine with python3 (AFAICT).
We also should probably be imposing a policy similar to Fedora and Mageia to force all Python shebangs to be versioned for installed scripts.
(1) Note that the version can be imposed without an absolute path: `#!/usr/bin/env python3` and `#!/usr/bin/env python2`.
/usr/bin/env python3 is 'fine' for local stuff done by yourself - but is plain wrong for packages provided by the distro. There, the packages are supposed to be integrating to each others and 'risking' to use any random 'python interpreter other than the one provided by the packaging system' is not what the distro should aim for.
(2) If absolute paths are used can this be done without encouraging upstream to use such shebangs? Absolute paths make it difficult to run up-to-date software on systems where there is no or too old python[23] in /usr/bin. If `env` is used I can at least help myself with a symlink in a folder early in $PATH (or a wrapper script if I also need to activate an environment first).
Preferably upstreams would make their build systems a bit smarter so that packagers can define what they want: 'local addon software' or 'package manager integrated stuff' BTW: '/usr/bin/env python' as shebang has the negative side effect of requriing /usr/bin/env in the rpm metadata of the package, but not actually any python interpreter. Using /usr/bin/python3 makes this correct and requires a python interpreter. Last but not least: we have an rpmlint check complaining about /usr/bin/env as shebang (for all the reasons outlined above). There are currently > 300 reports in Factory for this: https://rpmlint.opensuse.org/openSUSE:Factory/x86_64/standard?rule=env-scrip... Cheers, Dominique