Bug 7566 - python-thinlinc doesn't handle Python 3 programs
Summary: python-thinlinc doesn't handle Python 3 programs
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Other (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.13.0
Assignee: Pierre Ossman
URL:
Keywords: nikle_tester, prosaic
Depends on:
Blocks: 4586
  Show dependency treegraph
 
Reported: 2020-10-07 11:21 CEST by Pierre Ossman
Modified: 2021-07-09 14:56 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:
* ps should show a command line that works * sys.executable + sys.argv should give an arg vector that works * Python development should be enabled for development versions (*post), but not for stable versions


Attachments

Description Pierre Ossman cendio 2020-10-07 11:21:38 CEST
Right now our python-thinlinc symlink is set up to launch python 2.x. We will need something to launch python 3.x instead as we convert things.

We will also need to be able to launch both 2.x and 3.x during the porting phase so we can test things.
Comment 2 Pierre Ossman cendio 2021-05-17 08:53:37 CEST
Also note that some parts have their own hacks on how to start Python, e.g.e tl-ssh-askpass.
Comment 3 Pierre Ossman cendio 2021-06-17 16:07:09 CEST
All the complexity around python-thinlinc should hopefully not be needed going forward and we can choose to do something simpler. Most of it was to support Solaris, where users often had to get a current version of Python installed by hand.

So the plan is to remove all mechanism for allowing the user to select which Python is used. This means we can ship something that works right away and not have to wait for tl-setup to set things up.

For now we will also assume that /usr/bin/python3 gives us what we want (we will still do a version check though).

This means we could get away with using "#!/usr/bin/python3" as the hash-bang in all our scripts. However we'd like to be cautious and future proof things a bit, and also try to solve bug 2552. So the plan is to have a wrapper, e.g. "#!/opt/thinlinc/libexec/python3".

That path is chosen for various reasons:

  * Have an absolute path rather than using /bin/env to avoid users messing things up
  * Put it in libexec so that we don't pollute tab completions and such by being in $PATH
  * Put it in the /opt/thinlinc structure to avoid polluting things outside our namespace

The last point means we are still hard coding /opt/thinlinc in a bunch of places, blocking bug 2748. However that bug is not a priority at the moment so we leave that issue for another day.
Comment 11 Pierre Ossman cendio 2021-07-08 12:15:37 CEST
There should be no traces of python-thinlinc left. Everything should now be using the new wrapper instead.

> * ps should show a command line that works

Yup

> * sys.executable + sys.argv should give an arg vector that works

Yup, used by sudorelaunch
Comment 12 Pierre Ossman cendio 2021-07-09 09:33:30 CEST
We need to do something about the development mode flags before this is done.
Comment 15 Pierre Ossman cendio 2021-07-09 10:22:19 CEST
Fixed now. Development mode is now only enabled if thinlinc-release ends in "post".
Comment 16 Niko Lehto cendio 2021-07-09 14:56:02 CEST
Tested this on a Fedora 33 system.
﷐[U+1F5F8]﷑ ps should show a command line that works
﷐[U+1F5F8]﷑ sys.executable + sys.argv should give an arg vector that works
﷐[U+1F5F8]﷑ Python development should be enabled for development versions (*post), but not for stable versions

Looks good!

Note You need to log in before you can comment on or make changes to this bug.