<html><head></head><body><div class="yahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;"><div dir="ltr" data-setdir="false">I am familiar with the package rename process and it would not have the effect you might think it would.</div><div dir="ltr" data-setdir="false">If I provide an upgrade path to a new package name, e.g. slurm-xxx, the net effect would be to tell yum or</div><div dir="ltr" data-setdir="false">dnf-managed systems that the new package name for slurm is slurm-xxx. That would make the problem</div><div dir="ltr" data-setdir="false">worse by not only upgrading slurm from EPEL but also renaming it.</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">The way to handle the problem properly is to use any of the other methods I described earlier that make</div><div dir="ltr" data-setdir="false">the name collision moot, i.e. tell your systems that your local repo has a higher priority or that packages</div><div dir="ltr" data-setdir="false">in that repo are protected from upgrade or lock slurm onto a designated version.</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">If you accidentally got pulled into an upgrade that you didn't want, those are the steps to prevent it in the future.</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">You can easily create test cases for yum by placing (artificially) higher versions of the packages you want</div><div dir="ltr" data-setdir="false">to protect into a test repo. Then use yum protectbase or yum priorities to tell your system that your local repo</div><div dir="ltr" data-setdir="false">is protected and/or that the local repo has a higher priority than the test repo, depending on which yum plugins</div><div dir="ltr" data-setdir="false">you use. Then verify that that `yum check-update` does not report an upgrade for your test packages.</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">Phil</div><div id="yahoo_quoted_2551463472" class="yahoo_quoted">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div>
On Wednesday, February 3, 2021, 04:03:00 AM EST, Jürgen Salk <juergen.salk@uni-ulm.de> wrote:
</div>
<div><br></div>
<div><br></div>
<div><div dir="ltr">Hi Phil,<br clear="none"><br clear="none">assuming that all sites maintaining their own Slurm rpm packages must <br clear="none">now somehow ensure that these are not replaced by the EPEL packages <br clear="none">anyway, why wouldn't it be possible, in the long run, to follow the <br clear="none">Fedora packaging guidelines for renaming existing packages?<br clear="none"><br clear="none"><a shape="rect" href="https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages" target="_blank">https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages</a><br clear="none"><br clear="none">Best regards<br clear="none">Jürgen<br clear="none"><br clear="none"><div class="yqt0155478617" id="yqtfd33271"><br clear="none">On 03.02.21 01:58, Philip Kovacs wrote:<br clear="none">> Lots of mixed reactions here, many in favor (and grateful) for the add <br clear="none">> to EPEL, many much less enthusiastic.<br clear="none">> <br clear="none">> I cannot rename an EPEL package that is now in the wild without <br clear="none">> providing an upgrade path to the new name.<br clear="none">> Such an upgrade path would defeat the purpose of the rename and won't <br clear="none">> help at all.<br clear="none">> <br clear="none">> The best option, in my opinion, would be to use one of the following yum <br clear="none">> plugins:<br clear="none">> <br clear="none">> yum-plugin-versionlock<br clear="none">> yum-plugin-priorities<br clear="none">> yum-plugin-protectbase<br clear="none">> <br clear="none">> With one or more of these, you can lock slurm on a particular version <br clear="none">> (versionlock), prioritize one repo over another<br clear="none">> (priorities) or protect certain repos from any upgrade (protectbase). <br clear="none">> Using these plugins also closes the general problem<br clear="none">> of not wanting locally built packages ever to be upgraded until you deem <br clear="none">> otherwise. Name collisions become irrelevant.<br clear="none">> <br clear="none">> I can also do one of two other things:<br clear="none">> <br clear="none">> 1. Remove slurm from EPEL<br clear="none">> 2. Downgrade slurm in EPEL to a stable but older version that likely <br clear="none">> won't interfere with most installations.<br clear="none">> <br clear="none">> Phil<br clear="none">> <br clear="none">> <br clear="none"></div></div></div>
</div>
</div></div></body></html>