Python Module Stream Default Change in AlmaLinux 9.4 and Its Effect on Kickstart Provisioning
0 reputation · 10 Sept 2023, 16:27 UTC
0 reputation · 10 Sept 2023, 16:27 UTC
Goal: achieve a repeatable development environment where the system Python interpreter version is predictable across fresh installations and automated image builds.
Constraint: AlmaLinux 9.4 changed the default dnf module stream for the python package from 3.9 to 3.11, a change documented in the 9.4 release notes under Application Streams. However, it remains unclear whether the python:3.11 stream is automatically enabled during a Kickstart‑based installation when no module stream is explicitly specified, leading to potential divergence between generic minimal installs and Kickstart files that omit the stream.
Uncertainty: without explicit stream handling, provisioning tools may install different Python versions depending on the media or automation used, compromising reproducibility.
Does the AlmaLinux 9.4 installer enable the python:3.11 stream by default in a Kickstart installation when no stream is declared? If not, what determines the selected stream in that scenario? How can administrators lock the stream to guarantee identical Python versions across both generic and Kickstart provisioning methods?
31775 reputation · 10 Sept 2023, 16:56 UTC
Yes, the AlmaLinux 9.4 installer will result in the python:3.11 stream being active, but not because the installer "enables" it. The default stream is defined in the AppStream repository metadata. When a Kickstart file omits a specific module directive, dnf resolves the python package to whatever stream the repository marks as default—which, in AlmaLinux 9.4, is 3.11. Consequently, a Kickstart installation and a generic minimal installation using the same 9.4 repositories will converge on the same version.
Confirmed: Module defaults are stored in the repository's metadata (modules.yaml). The installer (Anaconda) uses dnf to resolve dependencies; if no stream is specified, dnf follows the metadata's default. This is consistent across all installation methods.
Likely Explanation for Divergence: If you observe different Python versions between a minimal install and a Kickstart install, it is likely due to repository mismatch rather than installer logic. Potential causes include:
url or repo directive in the Kickstart pointing to a specific snapshot or older release.To guarantee identical versions regardless of the repository's default state, explicitly declare the stream in the main section of your Kickstart file:
module --name=python --stream=3.11This ensures that even if the system is provisioned against a 9.3 mirror or a future 9.5 mirror with a different default, the 3.11 stream is forced. For existing systems, you can converge the version via %post or configuration management:
dnf -y module enable python:3.11
dnf -y distro-syncThe distro-sync command is critical here to ensure any packages installed from a previous stream are upgraded or replaced to match the newly enabled stream.
Verify the active stream and interpreter on the provisioned host:
dnf module list python
python3 --versionIn the output of dnf module list, [d] indicates the repository default and [e] indicates the enabled stream. For a locked environment, 3.11 should be marked [e].
/usr/libexec/platform-python) is separate from the AppStream module and is not affected by these changes.module command in Kickstart requires a compatible version of Anaconda; verify this against the specific boot media used in your pipeline.If divergence persists after pinning, the one diagnostic detail required to change this recommendation is the specific AppStream repository URL used by the Kickstart process.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.