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

[Michael Jennings]

On Wednesday, 03 February 2021, at 18:06:27 (+0000),
Philip Kovacs wrote:

> 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's not wrong here.  Package renames must use "Obsoletes:" and
"Provides:" to facilitate the seamless migration from the old name to
the new name, and as a consequence of that, the end result will not
change; YUM/DNF will replace the site's Slurm RPMs with Phil's renamed
RPMs from EPEL.

In addition to the plugins Phil (and others) mentioned previously
(which really *are* the best ways to address this!), I'll share *my*
super-spiffy top secret way of handling this exact type of situation
(i.e., preventing site-maintained RPMs from being unintentionally
"upgraded"):  Epoch.  For any RPMs I personally build/maintain that
could possibly show up somewhere externally (i.e., stuff that's not
"LANL Internal Use Only/OUO"), I set the Epoch: header value to a
YYYYMMDD datestamp.

For example, I maintain my own RPM for Mutt, my e-mail client.  To
make sure my RPM always wins, my mutt.spec file has this:

    Epoch: %{expand:%(date +%%Y%%m%%d)}

This provides a build-date-stamped value for the Epoch header field.
(For anyone not familiar with Epoch, it's basically a package
versioning "trump card:"  Epoch comparison has the highest precedence
of all, overriding both Version and Release.  Whichever RPM has the
highest Epoch value wins, full stop.)  No matter what version of Mutt
might appear in EPEL or anywhere else, my RPM won't be touched because
of its extremely high Epoch.  (Typically even upstream RPMs that *do*
have Epochs set are done incrementally starting at 1, so they'd have
to mess up the versioning a spectacular number of times (specifically,
20,210,203 times and counting) to catch up to my RPM's Epoch! :-D

HTH,
Michael

-- 
Michael E. Jennings <mej at lanl.gov> - [PGPH: he/him/his/Mr]  --  hpc.lanl.gov
HPC Systems Engineer   --   Platforms Team   --  HPC Systems Group (HPC-SYS)
Strategic Computing Complex, Bldg. 03-2327, Rm. 2341    W: +1 (505) 606-0605
Los Alamos National Laboratory,  P.O. Box 1663,  Los Alamos, NM   87545-0001