[packages/python-sympy] - up to 1.7.1, python 2 no longer supported

[Jakub Bogusz]

On Fri, Mar 12, 2021 at 10:25:36AM +0100, Jan Rękorajski wrote:
> On Fri, Mar 12, 2021 at 9:55 AM Elan Ruusamäe <glen at pld-linux.org> wrote:
> 
> >
> > On 12.03.2021 00:32, baggins wrote:
> > > commit a7afb2642f193eb728569b130fd57bdc8acadd02
> > > Author: Jan Rękorajski <baggins at pld-linux.org>
> > > Date:   Thu Mar 11 23:32:30 2021 +0100
> > >
> > >      - up to 1.7.1, python 2 no longer supported
> > >
> > >   python-sympy-nodisplay.patch | 25 -------------------------
> > >   python-sympy.spec            |  8 +++-----
> > >   2 files changed, 3 insertions(+), 30 deletions(-)
> > > ---
> > > diff --git a/python-sympy.spec b/python-sympy.spec
> > > index cb6d2e4..6c9214c 100644
> > > --- a/python-sympy.spec
> > > +++ b/python-sympy.spec
> > > @@ -2,20 +2,19 @@
> > >   # Conditional build:
> > >   %bcond_without      doc     # HTML and PDF documentation
> > >   %bcond_without      tests   # unit tests
> > > -%bcond_without       python2 # CPython 2.x module
> > > +%bcond_with  python2 # CPython 2.x module
> > >   %bcond_without      python3 # CPython 3.x module
> > >
> >
> > i agree with what qboosh has been doing in this cases:
> >
> > 1. git ssh copy python-foo to python3-foo
> >
> > 2. update python3-foo to be python3 only
> >
> > 3. update python3-foo to new version, stb
> >
> > 4. disable python3 from python-foo, relup, stb
> >
> 
> And I very much do not agree with that.
> Python 2 must die. If upstream decides to drop python2 support, we should
> too,
> we should not keep old odd versions indefinitely[1].  This creates chaos
> because
> we end up with inconsistent mess.
> 
> [1] We may, but only for a very strong reasons, ex. a ton of packages would
> break.

Python 2 is dying, more and more (mostly very common) packages are dropping support,
but there are still/will be "long tails" of not ported single packages.

Mainstream is slowly porting from gtk+ 3 to gtk 4 and we still have gtk+ 1.

Ofc, there is no sense to keep all active forever, python2 packages can
fade out from the "loose" (non-required) ends.

For the active cases - as we didn't go Fedora way with renaming all
python 2.x packages to python2-*, I see two possibilities:

a) python-foo.spec with python2-only module/version of module or python2/3 modules
  and python3-foo.spec with python3-only module/version of module

b) python-foo.spec:master branch with python3-only module/version of module or python2/3 modules
  and python-foo.spec:PYTHON2 branch with last supported python2 version

I personally prefer a) because:
- we can build all active packages from repo heads (I am aware of just two
  exceptions from this "rule": kernel.spec and php.spec)

- in case of python3-only spec, we need only one package preamble
  (b) case requires dummy base package and "-n python3-foo" subpackage)

In case of b), in python3-only cases apidocs should be packaged as
"%package -n python3-*-apidocs", not "%package apidocs".

> it takes extra steps to do that, but i think it's worth the effort in
> > long term.
> >
> > it's weird to have python-foo to build python3-foo,
> > and the python3-foo will be cleaner without having to support two python
> > versions.
> >
> 
> What we should do here is to just drop python2 from python-foo, what I'll
> do once
> the dust after current 3.9 / rpm deps rebuild settles.

Keeping dead python2 boilerplate in spec (just with bcond off) after updating
to python3-only version makes no sense...


As for establishing some python2/3 packaging/migration policy - where to
Obsolete python-* packages after dropping python2 variants?


-- 
Jakub Bogusz    http://qboosh.pl/