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? All the best, Tomas