On Fri, 22 May 2020 at 10:42, Miro Hrončok <mhroncok@redhat.com> wrote:
[..]
It is just the component name. The user installable package is still python3.

I call it thing-which-should-not-exist or thing-which-shall-not-pass.
That way it is easier to pronounce 😋
Reasoning:

Build python3, python3-libs etc. from python39 SRPM on F33+:

https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/message/5QUN7FWI6AV7BTMQGF257BEVMEA4QFOG/


Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9):

https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/message/VIUS7WMQMDX6H2WEIH7TVTMBB6SUHY7E/

A .. yeah 🤦‍♂️
You are right I forgot that Fedora on making new major release instead branching all packages stored in git still provides on master full support for all last three version of the distribution, three EPL/RHEL and sometimes even few version of SuSE 🙄

I must apologise: sorry looks like it is my mistake .. (mea culpa, mea culpa, .. mea maxima culpa)

[mode=serious]
On making transition from 3.8.x to 3.9.x all what would be necessary to do would be just create compat-python3.8 package -> upgrade python.spec to 3.9 -> monitor number of packages still dependent on  compat-python3.8 to focus what still needs to be ported/rebuild.
Because other factors the best moment to start such transition would be few days after f32 official release and tag all git resources and just right before first MR.
Because rawhide just after that will have in %{dist} "f33" it will be not even necessary to do what started today (bumping all python packages releases and committing those changes) because <foo.version>-<bar.release>.f32 will be always lower than  <foo.version>-<bar.release>.f33.

To make all above possible all only what would be is to stop using python packages names in Requires and BuildRequires and start using %pythondist(<module> similar to what is now with  pkgconfig() dependencies (nice clean and not even one new macro needs to be introduced/split on some exact package major version release).

With above total entropy cost would be ONLY:
- one additional compat-python3.8 package
- redefine %pythondist macro to provide python versioned dependencies (probably by change only version in the macro which should hold python major version).

On top of such scheme it will be possible go back to old simpler maintenance of the long term used systems by combing only all installed compat-* packages .. nice, easy and clean.

pkgconfig proved that this is actually and already/perfectly working (only adaptation still is sloppy), and I don't see literally even single reasons why it should not work for python or gt4/kde4 vs. qt4/kde5 as well.

Isn't it?
[/mode]

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH