[meta-python2][PATCH 1/1] python: use update-alternatives for python link
|
Joe Slater
Make the link of python to python2.7 an alternative. This
allows python3 to provide a link if we are not around, but makes our link override any python3 provides, assuming he uses the default priority. Signed-off-by: Joe Slater <joe.slater@...> --- recipes-devtools/python/python_2.7.18.bb | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/recipes-devtools/python/python_2.7.18.bb b/recipes-devtools/python/python_2.7.18.bb index 7350562..3faf154 100644 --- a/recipes-devtools/python/python_2.7.18.bb +++ b/recipes-devtools/python/python_2.7.18.bb @@ -34,7 +34,14 @@ SRC_URI += " \ S = "${WORKDIR}/Python-${PV}" -inherit autotools multilib_header python-dir pythonnative ptest +inherit autotools multilib_header python-dir pythonnative ptest update-alternatives + +# Make 'python' an alternative so that if python3 also provides it, we will be the default. +# +ALTERNATIVE_${PN}-core = "python" +ALTERNATIVE_LINK_NAME[python] = "${bindir}/python" +ALTERNATIVE_TARGET[python] = "${bindir}/python${PYTHON_MAJMIN}" +ALTERNATIVE_PRIORITY[python] = "50" EXTRA_OECONF += "--with-system-ffi" -- 2.29.2 |
|
|
|
Martin Jansa
As this wasn't needed until now and python3 also doesn't use u-a for ${bindir}/python as all python3 scripts should explicitly call python3, why do you think it would be worth adding to dead python2 recipe? If you need this symlink would it make sense to use separate recipe like python-is-python2/python-is-python3 packages in debian based systems and create the symlink there instead of u-a in python itself? On Tue, Jul 6, 2021 at 8:19 PM Joe Slater <joe.slater@...> wrote: Make the link of python to python2.7 an alternative. This |
|
|
|
Joe Slater
Sorry for the delay, but I your message got put in a folder I don’t look at much. Some projects, like blktrace, have scripts that work with python2 or python3 and want to leave the shebangs “generic”. Of course, that won’t work if python3 doesn’t supply “python”. I admit that wanting to put both python2 and python3 in an image is weird, but we could do it and have both versions supply “python”.
I don’t see any downside to making “python” a u-a link. It’s already a link. I admit, though, that there is no guarantee python3 will be allowed to supply a u-a link.
Joe
From: Martin Jansa <martin.jansa@...>
Sent: Friday, July 9, 2021 5:07 AM To: Slater, Joseph <joe.slater@...> Cc: openembedded-devel <openembedded-devel@...>; MacLeod, Randy <Randy.MacLeod@...> Subject: Re: [oe] [meta-python2][PATCH 1/1] python: use update-alternatives for python link
As this wasn't needed until now and python3 also doesn't use u-a for ${bindir}/python as all python3 scripts should explicitly call python3, why do you think it would be worth adding to dead python2 recipe?
If you need this symlink would it make sense to use separate recipe like python-is-python2/python-is-python3 packages in debian based systems and create the symlink there instead of u-a in python itself?
On Tue, Jul 6, 2021 at 8:19 PM Joe Slater <joe.slater@...> wrote:
|
|
|
|
Martin Jansa
Would it make sense to replace shebang in such scripts to explicitly call python3? As it's not only the u-a for the python symlink, but RDEPENDS of the package should pull the right interpreter as well. Always installing supported python3-core for blktrace scripts is IMHO much better than allowing blktrace script so run with EOL python2 in some weird case when python2 is in the image and python3 isn't. At least that's what I'm doing with generic shebangs in meta-ros recipes. Also as you might have noticed the target python is already blacklisted in this layer. On Mon, Jul 19, 2021 at 11:45 PM Joe Slater <joe.slater@...> wrote:
|
|
|