https://bugzilla.redhat.com/show_bug.cgi?id=2488341
--- Comment #2 from Adrian Reber <[email protected]> --- 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. -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2488341 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202488341%23c2 -- _______________________________________________ package-review mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
