Installing python packages for Python 3.11 on Rocky Linux 9.3 (Blue Onyx)

Hello Team,

We are trying to migrate our existing application from Python 3.9 to Python 3.11 . We observed that RPM’s for following Python packages are not available for Python 3.11.

  • iotop - Installed by iotop-0.6-30.el9.noarch RPM
  • nftables - installed by python3-nftables-1.0.4-10.el9_1.x86_64 RPM
  • sepolicy - python3-policycoreutils-3.5-1.el9.noarch RPM
  • subscription-manager - subscription-manager- RPM

These RPM’s are installing only for Python 3.9 and RPM’s for Python 3.11 are not available. Python 3.11 RPM package are available for few of Python packages. e.g.

python3.11-setuptools python3.11-gpg python3.11-rpm

Can you please check and confirm if this support is not added yet.

Default system python is 3.9, so dependencies won’t change for this. You can use python3.11, but the operating system will still need python3.9 for system-related stuff and this will not change for the entirety of Rocky 9.x - even future versions.

Rocky is based on RHEL, so it is the same as RHEL. If RHEL don’t change/update their package versions, Rocky won’t see those updates either. Rocky will not digress from package versions as Rocky aims to be 1:1 with RHEL.

One can basically see three “subsets”:

  • There is python. The “executable”
  • There are modules for python. “Libraries”
  • There are applications that run on python

The OS has “platform python” that – as said – will remain same until EOL of the distro.
There are alternative python versions (e.g. the 3.11) for user applications.

There are some modules (e.g. numpy) as RPM for each available python version, so that all users do not have to fetch all modules for their own needs (e.g. with pip install --user or venv).

The dnf, nft, iotop, etc are system applications that run with the platform python and hence stick to that version.

Look at Red Hat Enterprise Linux Application Streams Life Cycle - Red Hat Customer Portal
You should see that the Python 3.9 is supported to EOL of EL9, May 2032,
but the Python 3.11 application stream will retire already in May 2026.

If, for example, the package manager (dnf) would be shifted to depend on 3.11 now, then it would have to be shifted to 3.11+x relatively soon. IMHO, such frequent porting would be wasted effort and expose dnf to “novel bugs”. If the package management, firewall, and whatnot of distro are eaten by bugs, then nobody is happy …

Python 3.11 and the upcoming release of Python 3.12 in 9.4 are for maintenance/development work due to “breaking changes”, the removal of depreciated functions".

Hi @iwalker and @jlehtone - Thanks for your responses.

I agree that default Python version for Rocky Linux 9.2 will remain at 3.9 and 3.11 package are made available through appstream only.

I just want to confirm that RPM packages for mentioned Python packages are not provided by Rocky Linux itself. As 3.11 version RPM packages are available for few of Python packages

Also I hope we can install metntioned package through tarball on system. Please let me know if there is any other alternatives.

Shailesh Vaidya

Better than tarball, would be to use pip3 install. They can be easily removed as well.

You can check to see if any Python 3.11 packages exist potentially for EL distributions in say EPEL or other repositories.


pip3 install could not find required package.

sh-5.1# pip3 install nftables 
ERROR: Could not find a version that satisfies the requirement nftables (from versions: none)
ERROR: No matching distribution found for nftables

When I trace back for Python 3.9. I found that it’s installed through python3-nftables RPM package.

sh-5.1# rpm -q --filesbypkg  python3-nftables
python3-nftables          /usr/lib/python3.9/site-packages/nftables
python3-nftables          /usr/lib/python3.9/site-packages/nftables-0.1-py3.9.egg-info
python3-nftables          /usr/lib/python3.9/site-packages/nftables/
python3-nftables          /usr/lib/python3.9/site-packages/nftables/__pycache__
python3-nftables          /usr/lib/python3.9/site-packages/nftables/__pycache__/__init__.cpython-39.opt-1.pyc
python3-nftables          /usr/lib/python3.9/site-packages/nftables/__pycache__/__init__.cpython-39.pyc
python3-nftables          /usr/lib/python3.9/site-packages/nftables/__pycache__/nftables.cpython-39.opt-1.pyc
python3-nftables          /usr/lib/python3.9/site-packages/nftables/__pycache__/nftables.cpython-39.pyc
python3-nftables          /usr/lib/python3.9/site-packages/nftables/
python3-nftables          /usr/lib/python3.9/site-packages/nftables/schema.json

I could not find 3.11 equivalent package in also.

Shailesh Vaidya

This sounds like an XY problem. You’ve asked X (involving package support for 3.11 and system packages like nftables), solving for Y (which you’ve not sufficiently answered; migrating an application is not the answer). What is it that you’re actually trying to achieve by using python 3.11 alongside nftables, selinux, and subscription manager?

Why does your application need python 3.11 when the system default (which everything on the system relies on) is 3.9?

@nazunalika -

Apologies if it was confusing. I listed those Python 3.9 packages and am checking their availability in Python 3.11 as part of migration effort. Hence, I posted this query. I will try to explore how these packages are actually used in my application

We are trying to move to 3.11 as latest Python release in security status. As 3.9 will be EOL in 2025-10


Python 3.9 will be remain default python on Rocky Linux 9. Even beyond the end of life date, python 3.9 will be here to stay. Trying to force system utilities and libraries to use a newer python will cause various issues, if not break your system.

Standalone applications that need a newer python can use python 3.11 (and python 3.12 when it is released with rocky linux 9.4). There should be no expectation, however, of being able to hook into the system packages/libraries in python3.11 as it is not the default python.

Upstream Python 3.9 will EOL 2025-10. RHEL 9/Rocky 9 Python “3.9” will EOL 2032-05 and will be kept secure all the way.

The “Python 3.9” in RHEL 9 is not the upstream version. It is something that was forked from upstream version by Red Hat into separate branch that is maintained by RH with backports:

One simply does not mess with the core components (like nftable) of Enterprise Linux. If one does, the result is no more EL, will probably break, and you can keep the pieces (preferably isolated from all networks).

1 Like

Even though RHEL 9 will keep maintain Python 3.9 until 2032, most python packages will not do the same. Quite some packages already dropped Python 3.7, and based on past experience, their support for Python 3.9 will also be dropped soon after its EOL in 2025. My feeling is that in recent years, Python and its ecosystem evolve much faster, and sticking to one version for 10 years is getting harder and harder.

I used to copy .spec from Fedora and build my own python39-XXX rpms on Rocky 8. With Rocky 9, doing so for Python 3.11 or 3.12 is a bit more diffcult as Redhat changed their policy on supporting non-default Python versions. For example, as stated in this thread, switching the system-default python would cause issues (and DNF is just recently changed to hard-coding python3.9 instead of python3). I wonder if using venv+pip would be a more viable solution.

On assumption that most user applications are not in RPM-packages and do have their own requirements for what Python modules they do use, I’d say “yes”. Up to distinct venv for each application. IMHO, in worst case via conda.