Request for help understanding the process for inclusion of maintenace updates for a package

Rocky Linux Help & Support
1

Currently running Rocky Linux 9.5 - using it as my main development server, and due to major performance updates in Python over the standard included release, I’ve been using Python 3.12, specifically maintenance release 3.12.5. While trying to get the Black formatter running, I’ve encountered an issue where apparently Black refuses to run on 3.12.5 due to the following reason: “Python 3.12.5 has a memory safety issue that can cause Black’s AST safety checks to fail. Please upgrade to Python 3.12.6 or downgrade to Python 3.12.4”. It does not appear as if 3.12.4 is available in the repo, and 3.12.5 is the latest available in AppStream or CRB.

Can anyone help me understand the process for new maintenance releases of Python being added to the repositories? 3.12 has released 4 more maintenance releases since 3.12.5, now being up to 3.12.9. At this point, is my only option to build and install 3.12.6 or (even .9) from source? Thanks in advance!

2

Welcome to the forums!

For Rocky Linux, we generally follow what Red Hat releases for RHEL. It is rare for upstream (RHEL) to rebase any packages in the current stable version. In majority of cases, patches to address bugs or security fixes are backported. See this link for information on backporting.

For your particular situation, you have three options:

  • Wait for Rocky Linux 9.6 in May, which will come with python 3.12.9
  • Rebuild the current CentOS Stream 9 python3.12 package from here for example.
  • Try to install the CentOS Stream 9 packages as updates from here as an example.

Option 1 would require some patience. However, if you’re not able to wait for May, you have option 2 and 3.

Option 2 will require you to install epel-release and then mock. It will take some time to build. Read up on mock here. You have multiple python 3.12 source packages you can build:

You can setup and build with mock like below:

$ dnf install epel-release
$ dnf install mock
$ mock -r rocky-9-x86_64 /tmp/python3.12-3.12.6-1.el9.src.rpm

The results will be in /var/lib/mock/rocky-9-x86_64/result

Option 3 may work just fine; you will have to install/update the packages and find out though and I cannot personally recommend it. If you want to try, you have three different versions you can try these, just look under your architecture as needed:

If you find you run into issues, you should be able to dnf downgrade or dnf history undo them to get the Rocky Linux packages back.

1 Like
3

Hey nazunalika, thanks so much for the prompt response! I had originally considered asking this question in RHEL’s forum since I’m aware that Rocky is supposed to be a bug for bug replication of RedHat, but ended up asking here since Rocky is what we’re using.

I appreciate your thorough explanation though, and appreciate the links to documentation - helps me review some further material on the intricacies of the release process. I’m half considering tabling this process until May since I’ve already waited a month or two on wrestling with Black, so what’s another one or two, right? Regardless, thanks again so much for the response, and the welcome as well!