Bug 2488341

Summary: Review Request: slurm26.05 - versioned slurm package (EPEL 10 only)
Product: [Fedora] Fedora Reporter: Adrian Reber <adrian>
Component: Package ReviewAssignee: Nobody's working on this, feel free to take it <nobody>
Status: NEW --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: package-review
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Adrian Reber 2026-06-12 13:30:03 UTC 
Spec URL: https://lisas.de/~adrian/slurm26.05.spec
SRPM URL: https://lisas.de/~adrian/slurm26.05-26.05.1-1.el10.src.rpm
Description: 
Slurm is an open source, fault-tolerant, and highly scalable
cluster management and job scheduling system for Linux clusters.
Components include machine status, partition management,
job management, scheduling and accounting modules.
Fedora Account System Username: adrian

https://koji.fedoraproject.org/koji/taskinfo?taskID=146545378


Fedora and EPEL 8 and 9 already have a slurm package.
One problem with the EPEL 9 slurm package it is difficult to update.

This submission is based on the existing rawhide spec file.

This package is named slurm26.05 (rather than just "slurm") so that
multiple major versions of Slurm can be packaged in parallel. Each
major release uses a versioned package name matching its release
series, with Conflicts on the unversioned "slurm" packages to
prevent co-installation.

Slurm daemons and commands from different major versions are not
compatible with each other. Upgrading a cluster from one major
version to the next (e.g. 25.11 -> 26.05) requires a coordinated
shutdown and restart of all daemons. A versioned package name lets
administrators install the new version on the system before
performing the switchover, and avoids an unintended major-version
upgrade via a routine "dnf update".