Fedora Account System
Red Hat Associate
Red Hat Customer
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".
What's the strategy here in regards to the Fedora package? Normally the latest version will be packaged there first. This compat package is a newer version than what is currently in rawhide. Compat packages are usually needed when there is a need for a different version than the existing default. slurm isn't yet in EPEL 10, so it may be a better approach to update the rawhide spec file to version 26.05, and then fast-forward the epel10 branch to that commit. Once there is a default slurm package in EPEL 10, then future versions would make sense as versioned compat packages. If the intent is to move to a future where there are only versioned slurm packages, that change should happen in Fedora first before being brought to EPEL. Some examples: python-django5 / python-django6, python3.14 / python3.15 Technically compat packages qualify for a review exception, but there's no harm in doing a review anyways to verify the parallel or conflicting aspects. https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_exceptions What library soname version will this be? This is obscured in the spec file by an overly greedy glob, which is probably the first thing that needs to be fixed. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_listing_shared_library_files The rawhide package has these: libpmi.so.0 libpmi2.so.0 libslurm.so.44 libslurm_pmi-25.11.4.so libslurmfull-25.11.4.so If those are all different in the compat package, ideally the libs subpackage could be set up as a parallel package and not a conflicting one.
Thanks for taking a look at this. Your are starting with the hard questions 😉 (In reply to Carl George 🤠 from comment #1) > What's the strategy here in regards to the Fedora package? I haven't really thought about Fedora. This was an EPEL idea. As mentioned above the hard thing is that upgrades are not super simple. It comes down to restarting the services in the right order so it also isn't super complicated. But Fedora was not something I spent much time thinking about. > Normally the > latest version will be packaged there first. This compat package is a newer > version than what is currently in rawhide. So, your question made think more about it. The Fedora problem might not be so difficult after all as a Fedora release usually is no longer around than 14 months (or so). So if rawhide would actually contain the latest version it should still be supported once the release branched of from Fedora is EOL. > Compat packages are usually needed when there is a need for a different > version than the existing default. slurm isn't yet in EPEL 10, so it may be > a better approach to update the rawhide spec file to version 26.05, and then > fast-forward the epel10 branch to that commit. Once there is a default > slurm package in EPEL 10, then future versions would make sense as versioned > compat packages. If the intent is to move to a future where there are only > versioned slurm packages, that change should happen in Fedora first before > being brought to EPEL. Some examples: python-django5 / python-django6, > python3.14 / python3.15 Would it work to just have the versioned packages in EPEL? From what I wrote above the life-cycle of slurm should be long enough that for Fedora no major updates are necessary during a release. For EPEL having the versioned packages would be more important so that users can make explicit decision when upgrading to the next major release. So maybe for now a different approach would be to use the version that is in rawhide and create a branch for EPEL 10 and then work with the maintainers to update rawhide to the latest version. > Technically compat packages qualify for a review exception, but there's no > harm in doing a review anyways to verify the parallel or conflicting aspects. Okay. Good to know. > https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/ > #_package_review_exceptions > > What library soname version will this be? This is obscured in the spec file > by an overly greedy glob, which is probably the first thing that needs to be > fixed. > > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > #_listing_shared_library_files > > The rawhide package has these: > > libpmi.so.0 > libpmi2.so.0 > libslurm.so.44 > libslurm_pmi-25.11.4.so > libslurmfull-25.11.4.so > > If those are all different in the compat package, ideally the libs > subpackage could be set up as a parallel package and not a conflicting one. That is from my 26.05 package: /usr/lib64/libpmi.so.0 /usr/lib64/libpmi.so.0.0.0 /usr/lib64/libpmi2.so.0 /usr/lib64/libpmi2.so.0.0.0 /usr/lib64/libslurm.so.45 /usr/lib64/libslurm.so.45.0.0 /usr/lib64/libslurm_pmi-26.05.1.so /usr/lib64/libslurmfull-26.05.1.so So, probably not able to install in parallel.
I see that the regular slurm package is now updated in 26.05 in f45/rawhide. Thanks for getting that done. I also see that it has been branched for epel10 like I suggested, so this compat package seems to no longer be needed. A future compat package for a different version might be, and this slurm26.05 spec file can be a model for that, but wouldn't be used directly. Because of that I'll close this bug.