On Wed, Apr 29, 2020 at 10:28 AM Tomas Orsava <tors...@redhat.com> wrote: > > Hello everyone. > I’m working on a change to rename pythonXY packages to pythonX.Y, e.g. > python39 to python3.9. > > Motivation: > When you install an additional Python interpreter, the command that runs it > contains a dot (e.g. /usr/bin/python3.9) but the package name does not (e.g. > dnf install python39). > The name without a dot is a technical debt that we carry since (at least) the > python26 package in RHEL 5 for consistency. The name with the dot makes much > more sense to Red Hat Python maintainers. > It’s a minor inconsistency, but we'd like to get it right in RHEL, and since > RHEL splits off from Fedora, it will be bugging us still in 2030+ unless we > fix it now. Especially with the likely coming version 3.10 the package name > python310 is confusing. This will also get us in sync with e.g. Debian > package names. > > Backwards compatibility: > We plan to create new components in rawhide containing the dot (e.g. > python3.9) for all Python interpreters (except soon-to-be-retired python34 > and python26) and push the git commits from pythnoXY to them to preserve the > history. > The packages will Provide and Obsolete the old name without a dot (e.g. > python39). The current packages already provide the name with the dot, so > this will be just a switch between real name and virtual provide. > Therefore any package that depends on these components will continue to work > just fine. And in time we’d like to fix all of those to use the new name, > which is backwards compatible, because it is already provided now (as a side > note, the packages are generally just recommended, not required). > > Technical details: > There has been a recent rawhide-only change to the %python_provide macro that > acts on packages named `python3-foo` and adds for them a new Provide > `python38-foo`. > We’d like to change this to Provide `python3.8-foo` instead. > Since this has been rawhide-only so far, and because there’s no real reason > to depend on these provides yet, we don’t expect any breakage. > > What do you think? Do you foresee any problems?
I'm good with this plan, except for one thing I thought of we need to address: How do we do comparisons for python versions? Will we still have a %python_version_nodots macro so that we can do integer comparisons? I know that people have been abusing the %python3_pkgversion macro for doing this (which you shouldn't be doing!), so we need an official guideline for how to do those comparisons. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org 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/python-devel@lists.fedoraproject.org
