On 22/05/20 11:43 +0100, Tomasz Kłoczko wrote:
On Fri, 22 May 2020 at 10:42, Miro Hrončok <mhroncok@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx/message/5QUN7FWI6AV7BTMQGF257BEVMEA4QFOG/
Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9):
https://lists.fedoraproject.org/archives/list/python-devel@xxxxxxxxxxxxxxxxxxxxxxx/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]
Maybe you should make a proper change proposal to do this, instead of
just being sarcastic about the work other people are doing?
_______________________________________________
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
