On 9/5/20 2:19 PM, Gary E. Miller via devel wrote: > And yet, Gentoo, and others still ship 2.7. And end users still use it.
This is not a discussion about whether Gentoo should drop Python 2.7.
It's not a discussion about whether users should stop using Python 2
entirely. Perhaps we can intuit each other's views on those topics, but
that's not what is being discussed here.
NTPsec currently supports: Python 2 >= 2.6 or Python 3 >= 3.3
There are four possible sets:
A) !(Python 2 >= 2.6) and !(Python 3 >= 3.3).
That is, it has neither version of Python at all or neither meets the
minimum version.
B) (Python 2 >= 2.6) and !(Python 3 >= 3.3).
That is, either it has no Python 3 or its Python 3 is < 3.3.
C) (Python 2 >= 2.6) and Python 3 >= 3.3.
That is, it has both Python 2 and Python 3 in versions that meet
NTPsec's minimums.
D) !(Python 2 >= 2.6) and Python 3 >= 3.3.
That is, it has an acceptable Python 3, but no acceptable Python 2.
Category A is irrelevant, as NTPsec already does not run there.
Category B is the relevant case to the main purpose of this thread: the
proposal to drop Python 2 support.
If a system is in category B because that particular system doesn't have
Python 3 installed, but the distro ships Python 3 >= 3.3, the solution
is simple: install Python 3. That doesn't change anything with their
Python 2 environment. If the user has critical Python 2 code, it stays
working just as it was.
If a system is in category B because the distro does not ship Python 3
>= 3.3, then Eric's proposal to drop Python 2 support means dropping
support for that distro. An example of that is RHEL 6. Because RedHat's
support lifecycles are generally longer than other distros' support
lifecycles, it is likely that RHEL 6 is the last example of such a
distro. RHEL 6's security support ends in November. Once that happens,
the affected population are users who both want to run the latest NTPsec
and are running a distro version that is no longer receiving security
updates. Why is that a scenario that NTPsec needs to support? Doubly so
given NTPsec's otherwise aggressive stance on removing old stuff in the
name of maintainability and security?
Last year, the current release of essentially every distro was likely in
category C. Users could use NTPsec with either Python 2 or Python 3 (but
only whichever version was providing `python`; see below).
Now that Python 2 has been end-of-lifed upstream, category D is likely
to expand. In this category, users must use NTPsec with Python 3.
Unfortunately, building/using NTPsec on a Python 3-only system without a
`python` symlink to Python 3 (e.g. Ubuntu 20.04) currently does not work
at all.
The minor problem is that waf has a `python` shebang. If the distro
does not ship `python` (as is the case on Ubuntu 20.04 out of the
box), then `./waf` will not run.
Whether a Python 3-only system should symlink `python` to `python3`
is debatable. Both options have pros and cons. In the case of
Ubuntu, one option is the default (no `python`) and the other is
available by admin choice (by installing the python-is-python3
package).
The lack of `python` can be trivially worked around with `python3 waf`
if the user knows to do so. (We should update the INSTALL docs with a
note on that once the bigger problem is resolved.)
The bigger problem is that the installed scripts have a hardcoded
shebang of `/usr/bin/env python` so none of them work. That can be
addressed by subst'ing the shebangs as in !1166:
https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1166
--
Richard
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
