Bug 2418374 - Python 3.x interpreter packages are parallel installable but no module packages for older versions
Summary: Python 3.x interpreter packages are parallel installable but no module packag...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: python3.13
Version: 43
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Python Maintainers
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-12-02 16:27 UTC by Zoltan Boszormenyi
Modified: 2025-12-03 09:35 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2025-12-02 18:17:23 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Zoltan Boszormenyi 2025-12-02 16:27:49 UTC
Python interpreter major versions are available using versioned package names in F43:
python3.14, python3.13, ... down to python3.10.

But no modules are available for versions other than the current latest stable.

python3.nn-pip should be available for all the major Python versions provided by Fedora, so users may install the modules they need for any given Python version.

Case in point: bitbake versions for older Yocto project releases do not work with Python 3.14.

Reproducible: Always

Steps to Reproduce:
1. Install Fedora 43
2. Run: "dnf list python3.13*" or any other older version.
3. It shows very few number of packages, modules and pip notably missing.



Additional Information:
remirepo exists for supported PHP major versions, something similar is needed for Python.

Comment 1 Miro Hrončok 2025-12-02 16:35:00 UTC
So this is in fact correct, no 3rd prarty Python modules/packages are available for versions other than the main. We don't have the human power to maintain several separate Python stacks packaged as RPM packages in Fedora.

However, if you want pip, you have several options. See https://developer.fedoraproject.org/tech/languages/python/multiple-pythons.html

Alternativelly, running `python3.13 -m ensurepip --user` is also supported:

$ python3.13 -m ensurepip --user
$ python3.13 -m pip --version
pip 25.2 from /home/.../.local/lib/python3.13/site-packages/pip (python 3.13)
$ python3.13 -m pip install --user yocto
...

Comment 2 Zoltan Boszormenyi 2025-12-02 17:10:25 UTC
I tried building python-setuptools from here: https://koji.fedoraproject.org/koji/buildinfo?buildID=2819549

$ sudo dnf install python3.13-devel
$ rpmbuild --rebuild --define='python3_pkgversion 3.13' --with bootstrap python-setuptools-78.1.1-15.fc43.src.rpm

which resulted in a parallel installable module package:

python3.13-setuptools-78.1.1-15.fc43~bootstrap.noarch.rpm

The resulting rpm cannot be installed:

$ sudo dnf install python3.13-setuptools-78.1.1-15.fc43~bootstrap.noarch.rpm 
Updating and loading repositories:
Repositories loaded.
Failed to resolve the transaction:
Problem: conflicting requests
  - nothing provides python(abi) = 3.13 needed by python3.13-setuptools-78.1.1-15.fc43~bootstrap.noarch from @commandline
You can try to add to command line:
  --skip-broken to skip uninstallable packages

Why doesn't the python3.13 package provide "python(abi) = 3.13"?

The newly built package may be forcibly installed:

$ sudo rpm -ivh --nodeps python3.13-setuptools-78.1.1-15.fc43~bootstrap.noarch.rpm 

Then it allows importing pieces provided by this module:

$ python3.13
Python 3.13.9 (main, Oct 14 2025, 00:00:00) [GCC 15.2.1 20250924 (Red Hat 15.2.1-2)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import distutils
>>> 

When it's installed, the same package may be rebuilt without "--with bootstrap".
The resulting package needs a few more module packages to be built and installed.

If package builds are automated in koji (it isn't?), then it's simply a matter of adding --define='python3_pkgversion 3.nn' to the build matrix for the supported Python major versions.

But thanks, I will also try your suggestions.

Comment 3 Miro Hrončok 2025-12-02 17:20:40 UTC
> Why doesn't the python3.13 package provide "python(abi) = 3.13"?

To prevent Fedora packagers from accidentally building 3rd-party Python modules against it until such a solution is supported (currently, it is not).

> If package builds are automated in koji (it isn't?), then it's simply a matter of adding --define='python3_pkgversion 3.nn' to the build matrix for the supported Python major versions.

It's not that simple; we cannot add macro definitions to a build matrix and build multiple packages out of one source. Fedora packages don't work that way. There was modularity, which kinda promised to deliver this feature, but ultimately failed and was retired from Fedora: https://fedoraproject.org/wiki/Changes/RetireModularity

I see that this might look simple, but it isn't. Supporting multiple builds of multiple packages for multiple Pythons requires volunteers to drive that effort.

Comment 4 Zbigniew Jędrzejewski-Szmek 2025-12-02 18:17:23 UTC
Yeah, this is really not something to discuss in a ticket. In the current scheme of things, having modules packaged for multiple python versions is not going to happen. Nor would it even be particularly desirable, considering how Fedora works. Feel free to open a discussion on the devel list, but I think that trying to change status quo would require finding a bunch of new people to spend time on this.

Comment 5 Zoltan Boszormenyi 2025-12-03 09:35:29 UTC
(In reply to Miro Hrončok from comment #1)
> So this is in fact correct, no 3rd prarty Python modules/packages are
> available for versions other than the main. We don't have the human power to
> maintain several separate Python stacks packaged as RPM packages in Fedora.
> 
> However, if you want pip, you have several options. See
> https://developer.fedoraproject.org/tech/languages/python/multiple-pythons.
> html
> 
> Alternativelly, running `python3.13 -m ensurepip --user` is also supported:
> 
> $ python3.13 -m ensurepip --user
> $ python3.13 -m pip --version
> pip 25.2 from /home/.../.local/lib/python3.13/site-packages/pip (python 3.13)
> $ python3.13 -m pip install --user yocto
> ...

Just to document the solution if someone else needs to fix the same issue.

I tried your second suggestion together with a local PATH override
in my start script for bitbake so the "#!/usr/bin/env python3" shebang
finds an appropriate python3 version. Something like
https://serverfault.com/questions/579956/alias-doesnt-work-in-script-with-usr-bin-env-php

That worked for me now on F43 for an old Yocto 3.4 based build from 2021
with using Python 3.12 plus the necessary GCC 15 fix backports for a
handful of Yocto recipes that were already in place because of a previous
attempt on F42.


Note You need to log in before you can comment on or make changes to this bug.