Re: Why retire Python 2 packages and games that still work to end user ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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?

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. 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.

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.

> 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.

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.

And supporting multiple versions is not an argument for not having at least 
a python2 symlink and Provides: python2 in python27.

> Simply replacing the "python2" line iwth "python27" is not a difficent
> edit in most source code.

But it is still a completely unnecessary edit.

        Kevin Kofler
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux