[slurm-users] Exclude Slurm packages from the EPEL yum repository

[Philip Kovacs]

I am familiar with the package rename process and it would not have the effect you might think it would.If I provide an upgrade path to a new package name, e.g. slurm-xxx, the net effect would be to tell yum ordnf-managed systems that the new package name for slurm is slurm-xxx.  That would make the problemworse by not only upgrading slurm from EPEL but also renaming it.
The way to handle the problem properly is to use any of the other methods I described earlier that makethe name collision moot, i.e. tell your systems that your local repo has a higher priority or that packagesin that repo are protected from upgrade or lock slurm onto a designated version.
If you accidentally got pulled into an upgrade that you didn't want, those are the steps to prevent it in the future.
You can easily create test cases for yum by placing (artificially) higher versions of the packages you wantto protect into a test repo.  Then use yum protectbase or yum priorities to tell your system that your local repois protected and/or that the local repo has a higher priority than the test repo, depending on which yum pluginsyou use. Then verify that that `yum check-update` does not report an upgrade for your test packages.

Phil   On Wednesday, February 3, 2021, 04:03:00 AM EST, Jürgen Salk <juergen.salk at uni-ulm.de> wrote:  
 
 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
> 
> 
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schedmd.com/pipermail/slurm-users/attachments/20210203/63bf1714/attachment.htm>