_pythonSymlinkCheck fails to account for use of update-alternatives

[michael]

In order to deal with the fact that users often modify /usr/bin/python DistUpdgradeControler.py attempts to verify it is set to the correct version:
...
 fs_default_version = os.readlink('/usr/bin/python')
 except OSError as e:
                logging.error("os.readlink failed (%s)" % e)
                return False
            if not fs_default_version in (expected_default, os.path.join('/usr/bin', expected_default)):
...

This check fails to account for setups using update-alternatives. In this case /usr/bin/python always points to another symlink ( i.e /etc/alternatives/python). This makes the above check always fail regardless of the python version actually running.

sys.version_info should be used instead as it makes no assumptions about how python was invoked.

"%s.%s.%s" %(sys.version_info[0],sys.version_info[1],sys.version_info[2])"%s.%s.%s" %(sys.version[0],sys.version_info[1],sys.version_info[2])

Yields the version string (i.e '2.7.15') for the running python interpreter.

[Julian Andres Klode (juliank)]

So, you want to execute python in a subprocess and read its output?

cosmic is also broken as documented in bug 1800823, as python is a symlink to python2.

We probably should sanity check all of python, python2, python3.

[michael (reeves-87)]

On Wed, Oct 31, 2018, 7:41 AM Julian Andres Klode <
<email address hidden> wrote:

> So, you want to execute python in a subprocess and read its output?
>
> cosmic is also broken as documented in bug 1800823, as python is a
> symlink to python2.
>
> We probably should sanity check all of python, python2, python3.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1798872
>
> Title:
> _pythonSymlinkCheck fails to account for use of update-alternatives
>
> Status in ubuntu-release-upgrader package in Ubuntu:
> New
>
> Bug description:
> In order to deal with the fact that users often modify /usr/bin/python
> DistUpdgradeControler.py attempts to verify it is set to the correct
> version:
> ...
> fs_default_version = os.readlink('/usr/bin/python')
> except OSError as e:
> logging.error("os.readlink failed (%s)" % e)
> return False
> if not fs_default_version in (expected_default,
> os.path.join('/usr/bin', expected_default)):
> ...
>
> This check fails to account for setups using update-alternatives. In
> this case /usr/bin/python always points to another symlink ( i.e
> /etc/alternatives/python). This makes the above check always fail
> regardless of the python version actually running.
>
> sys.version_info should be used instead as it makes no assumptions
> about how python was invoked.
>
> "%s.%s.%s"
> %(sys.version_info[0],sys.version_info[1],sys.version_info[2])"%s.%s.%s"
> %(sys.version[0],sys.version_info[1],sys.version_info[2])
>
> Yields the version string (i.e '2.7.15') for the running python
> interpreter.
>
That would be one way. I was perposing the use of sys.version_info. This is
built-in python variable that tells what the currently running interpreter
version is regardless of how it was started. My understanding is that this
is intended as a compatibility check. In that case its the running python
version the should concern us.

>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1798872/+subscriptions
>

[michael (reeves-87)]

sys.version_info is a runtime check of the actual version of python running. This is what we care about not enforcing a setup.

[michael (reeves-87)]

Sorry for repeating already sent information would you be open to a patch for this?