packages/lang/python/python-package-install.sh, branch openwrt-18.06

python,python3: Fix overridden usr/bin symlinks

2019-08-08T11:38:37Z

Currently, all files in usr/bin (presumably all Python scripts) are run through sed to replace the shebang; sed will overwrite the file whether or not a match is found. This causes symlinks to be overridden and made into copies of their targets. python[3]-base and python[3]-dev are affected by this. This adds the --follow-symlinks flag to sed, in addition to using $(SED), so that symlinks are not overridden. Signed-off-by: Jeffery To

python,python3: move shebang handle in install script

2019-08-08T11:38:36Z

This extends the Python[3] shebang fixup to all packages. Only Python scripts in `/usr/bin` will be handled at the moment. Later it may make sense to also cover executables in `/bin`, though typically Python executables shouldn't be placed there. Previously the shebang handling was only done for python[3]-pip & python[3]-setuptools. Signed-off-by: Alexandru Ardelean

lang/python/python-package-install.sh: assign SOURCE_DATE_EPOCH to PYTHONHASHSEED

2018-03-07T18:52:15Z

Following a discussion on bugs.python.org: * https://bugs.python.org/issue29708 * https://bugs.python.org/msg313384 It seems that setting a fixed value to PYTHONHASHSEED guarantees that the bytecodes are generated consistently/in a reproducible manner. Hopefully, this is the last bit to make Python3 build reproducible. Tested this locally on a few files [that were not reproducible without this change]. The PYTHONHASHSEED is only assigned to the host Python/Python3 during compilation of byte-codes [from python source]. Signed-off-by: Alexandru Ardelean

python,python3: merge package install scripts

2018-01-10T21:06:22Z

The only difference just a parameter for Python3 [ -b to compile bytecodes in legacy mode ]. No need to keep 2 almost identical files now that they're exported. I'm a bit scared of that param, since it may get removed at some point. But let's see until then. Signed-off-by: Alexandru Ardelean

python,python3: export mk files outside of python package dirs

2018-01-10T21:01:51Z

Since `lang/python` is it's own folder of Python packages (for both Python 2 & 3), and these build rules are needed in a lot of packages [especially Python packages], putting them here makes sense architecturally, to be shared. This also helps get rid of the `include_mk` construct which relies on OpenWrt core to provide, and seems like a broken design idea that has persisted for a while. Reason is: it requires that Python 2/3 be built to provide these mk files for other Python packages, which seems like a bad idea. Long-term, there could be an issue where some other feeds would require these mk files [e.g. telephony] for some Python packages. We'll see how we handle this a bit later. For now we limit this to this feed. Signed-off-by: Alexandru Ardelean