Hi Phil,
assuming that all sites maintaining their own Slurm rpm packages must
now somehow ensure that these are not replaced by the EPEL packages
anyway, why wouldn't it be possible, in the long run, to follow the
Fedora packaging guidelines for renaming existing packages?
https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages
Best regards
Jürgen
On 03.02.21 01:58, Philip Kovacs wrote:
Lots of mixed reactions here, many in favor (and grateful) for the add
to EPEL, many much less enthusiastic.
I cannot rename an EPEL package that is now in the wild without
providing an upgrade path to the new name.
Such an upgrade path would defeat the purpose of the rename and won't
help at all.
The best option, in my opinion, would be to use one of the following yum
plugins:
yum-plugin-versionlock
yum-plugin-priorities
yum-plugin-protectbase
With one or more of these, you can lock slurm on a particular version
(versionlock), prioritize one repo over another
(priorities) or protect certain repos from any upgrade (protectbase).
Using these plugins also closes the general problem
of not wanting locally built packages ever to be upgraded until you deem
otherwise. Name collisions become irrelevant.
I can also do one of two other things:
1. Remove slurm from EPEL
2. Downgrade slurm in EPEL to a stable but older version that likely
won't interfere with most installations.
Phil
