On 11. 08. 19 3:45, Kevin Kofler wrote:
Nico Kadel-Garcia wrote:
Maintaining python 2 requires maintaining a*lot* of infrastructure.
What kind of infrastructure do you need to maintain a package that is (will
be) no longer updated upstream? This takes almost no work. The only thing to
do is to backport some security fixes from Python 3, and occasionally to fix
FTBFS bugs.
We are still planning to maintain the interpreter. As is documented in the
change. So can we please stop arguing about maintaining the interpreter over and
over? It is staying and our team will maintain it at least until RHEL 7 EOL,
possibly longer.
Now if your concern is maintaining all the python2-* packages, then there
ought to be some middle ground between maintaining all of them including
ones that are not used by anything in Fedora anymore, and just dropping all
of them (with or without the planned exception process, whose usefulness
depends entirely on how willing FESCo will be to approve the requests).
Maybe the set of python2-* modules in EL7 or EL8, with or without EPEL,
minus the ones already retired from Fedora by now, would be a reasonable
starting point?
Yes the concern is about maintaining the python2-* packages.
The difference between EL and Fedora is that package sin Fedora get recent
rebases / updates to newer version. You cannot just package them and call it
"done". And most of the upstreams are coming to a point where you cannot update
the Python 2 package because the new version doe snot support Python 2.
That at the end means you need to go over nonobvious bumps to split the Python 2
package out of the "common" package, in order to update the "common" (now Python
3 only) package. And this problem spreads further with dependencies (even
transitive ones). I don't have the energy or time to split hundreds of packages
and maintain a separate stack of Python 2 packages. If somebody else has, go for it.
The set of python2-* packages to remain is determined by the FESCo exceptions.
It is fairly easy really: We don't have the necessary information to understand
what Python packages are "important" and what are "cruft". Hence if your package
is important, you just need to explain that. Obviously, if you need to maintain
the package as a dependency, for another important package, the exception can be
requested at once, you don't need to request dozens of exception to keep e.g.
chromium around.
I also think that there ought to be more cooperation from the maintainers of
individual python2-* modules. The approved Fedora 31 Change makes it way too
easy for maintainers to just drop Python 2 support for no reason.
When a packager doesn't want to maintain it, that's good enough reason.
You have a right to orphan a package, why you should not have the right to
orphan a half of your package, when he other half works without it?
If
upstream dropped Python 2 support from the current version and so an old
version has to be packaged specifically for Python 2, that is one good
reason to require somebody else to pick up maintenance, but as it stands, no
such reason is required and Fedora maintainers can arbitrarily drop Python 2
support from their Python modules even if upstream still supports it. This
is just pointless and unhelpful.
Requiring others to maintain the packages your packages (or you) need just
because they maintained it until now is not very friendly. Of course, you can
ask nicely, but you cannot say this is their duty.
We can try to find people to pick up python2 and a bunch of python2-*
modules, but expecting the python2 maintainer(s) to sign up for maintaining
each and every python2-* module is unreasonable and unrealistic. Even if
several of them will also be dead upstream (at least the version that works
with Python 2) and thus require very little maintenance effort.
Arguably, maintaining dead software requires more effort than maintaining live
one. But that kinda depends on the particular package.
I don't need people to maintain **all** Python 2 packages, just mine. But
possibly other maintainers also don't want to maintain theirs. As the snowball
rolls, you need somebody to maintain **almost all** of them.
To support multiple pythons, python26, python28 if it ever happens,
python36 python38 when it comes out.
The whole reason for this discussion is that Python 2.8 will likely never
happen. It definitely will not happen from Python upstream. Otherwise, there
would not be all this talk about dropping Python 2 due to being unsupported
upstream.
Correct. We just want to signal that this is a compat package. We will most
likely still provide python2 (so users can discover it more easily). Why is the
package name so important to you?
I don't see much point in supporting Python 2.6, which is even more ancient
than Python 2.7, and 2.7 is backwards-compatible with 2.6.
The point is to support developers who use Fedora as they workstation but need
to support and test Python 2.6 (e.g. on EL6) in their code. Nevertheless, the
python26 package is now orphaned, because one of the dependencies is orphaned
(compat-openssl10).
And supporting multiple versions is not an argument for not having at least
a python2 symlink and Provides: python2 in python27.
Correct. Except both of those to happen.
Simply replacing the "python2" line iwth "python27" is not a difficent
edit in most source code.
But it is still a completely unnecessary edit.
Yes.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
