<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">What you are describing is implemented in the EL ecosystems as module streams. Streams are setup by maintainers</div><div dir="ltr" data-setdir="false">to correspond to major version trains of software. Users can then select the stream they want and can change streams</div><div dir="ltr" data-setdir="false">as desired (unfortunately this is often not trivial), without upgrading or downgrading their systems. It's a lot of extra work</div><div dir="ltr" data-setdir="false">and misery for maintainers to manage several independent working streams, however, so projects such as "Modularity"</div><div dir="ltr" data-setdir="false">have received a fair amount of criticism for that and other reasons.</div><div id="yahoo_quoted_2684682020" class="yahoo_quoted">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div>
On Wednesday, February 3, 2021, 01:32:27 PM EST, Ryan Novosielski <novosirj@rutgers.edu> wrote:
</div>
<div><br></div>
<div><br></div>
<div><div dir="ltr">My main point here is that essentially upgrading someone from, for example, SLURM 20.02 to SLURM 20.11 is not desirable, and that’s why upgrades between major versions, IMO, should not happen automatically. There’s a whole section of the documentation about how to do this properly, and I’m not sure that one should ever count on a package to do this properly, at least without advance planning (which I guess you could argue someone should do anyway). That doesn’t have much to do with the initial complaint of them just appearing, which is a one-time problem as now it’s in the repo. At any rate, not wanting to upgrade automatically is at least true of slurmdbd and slurmctld, maybe less true of the client versions. Sure, someone should know what they’re upgrading to, but I don’t imagine anyone’s goal here is to make it easier to shoot oneself in the foot. I imagine no one releases packages with the express goal of having people version lock them out. :-D<br clear="none"><br clear="none">None of this affects me, as I’m not installing SLURM this way, but if someone /were/ asking me what I thought, I’d say that the current “slurm” package should be renamed “slurm-20.11,” which can follow an upgrade path with no issue as it’s safe to upgrade within a SLURM release, but that should only ever upgrade to another minor release of SLURM 20.11. The next one should be called slurm-21.02 or whatever version it ultimately becomes (I don’t think it’s even been pre-released yet). I don’t know enough about EPEL to know if that’s an allowable solution, but it’s one I’ve seen used for other software packages where one needs to manually upgrade to a new major version (I’m thinking on Ubuntu where the VirtualBox package has an embedded major/minor version number in it so you only automatically upgrade to a new point release).<br clear="none"><br clear="none">To give an example of why we don’t just upgrade via packages, our SlurmDBD upgrade has at times taken more than 24 hours to do, and if something else gets upgraded sometime before that, it could cause problems.<br clear="none"><br clear="none">--<br clear="none">#BlackLivesMatter<br clear="none">____<br clear="none">|| \\UTGERS, |---------------------------*O*---------------------------<br clear="none">||_// the State | Ryan Novosielski - <a shape="rect" ymailto="mailto:novosirj@rutgers.edu" href="mailto:novosirj@rutgers.edu">novosirj@rutgers.edu</a><br clear="none">|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus<br clear="none">|| \\ of NJ | Office of Advanced Research Computing - MSB C630, Newark<br clear="none"> `'<br clear="none"><div class="yqt6082480999" id="yqtfd98335"><br clear="none">> On Feb 3, 2021, at 1:06 PM, Philip Kovacs <<a shape="rect" ymailto="mailto:pkdevel@yahoo.com" href="mailto:pkdevel@yahoo.com">pkdevel@yahoo.com</a>> wrote:<br clear="none">> <br clear="none">> I am familiar with the package rename process and it would not have the effect you might think it would.<br clear="none">> If I provide an upgrade path to a new package name, e.g. slurm-xxx, the net effect would be to tell yum or<br clear="none">> dnf-managed systems that the new package name for slurm is slurm-xxx. That would make the problem<br clear="none">> worse by not only upgrading slurm from EPEL but also renaming it.<br clear="none">> <br clear="none">> The way to handle the problem properly is to use any of the other methods I described earlier that make<br clear="none">> the name collision moot, i.e. tell your systems that your local repo has a higher priority or that packages<br clear="none">> in that repo are protected from upgrade or lock slurm onto a designated version.<br clear="none">> <br clear="none">> If you accidentally got pulled into an upgrade that you didn't want, those are the steps to prevent it in the future.<br clear="none">> <br clear="none">> You can easily create test cases for yum by placing (artificially) higher versions of the packages you want<br clear="none">> to protect into a test repo. Then use yum protectbase or yum priorities to tell your system that your local repo<br clear="none">> is protected and/or that the local repo has a higher priority than the test repo, depending on which yum plugins<br clear="none">> you use. Then verify that that `yum check-update` does not report an upgrade for your test packages.<br clear="none">> <br clear="none">> <br clear="none">> Phil<br clear="none">> On Wednesday, February 3, 2021, 04:03:00 AM EST, Jürgen Salk <<a shape="rect" ymailto="mailto:juergen.salk@uni-ulm.de" href="mailto:juergen.salk@uni-ulm.de">juergen.salk@uni-ulm.de</a>> wrote:<br clear="none">> <br clear="none">> <br clear="none">> 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">> <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"><br clear="none"></div></div></div>
</div>
</div></div></body></html>