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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Apr 29, 2020 at 10:28 AM Tomas Orsava <torsava@xxxxxxxxxx> 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!
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux