-
Notifications
You must be signed in to change notification settings - Fork 205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support uninstalling software + module #590
Comments
Our policy is to only delete something if it actually was installed wrongly or by accident, and then do delete it as soon as possible, before anybody starts using it. This is very easy (and easy to add to easybuild too I imagine), just remove the install folder ($EBROOTXXX) and remove the module file. However, how should we handle reverse dependencies? |
+1 and especially, this would help greatly for doing cleanup after releases
|
I concur too, there should be a way to remove old versions of software. I agree this requires keeping track of the dependencies, and offer an option to remove or at least warn about packages affected by the removal. This could be handled in a flat file stored in $EBROOTEASYBUILD or somewhere, that would keep track of what's installed and of the dependencies. Otherwise, there's no way to remove older versions of packages once they're not used anymore. This is fine for the short-term, but on the longer term, ending up with hundreds of modules is not something users can easily deal with. |
Why not keep it simple and just implement
Yes, this will break anything that depends on the software just removed, but well there's a thousand ways a sysadmin can break a running system :-) and this one can be easy undone by EB itself ;-) |
Yeah, that's a reasonable suggestion. But, without We haven't done that yet because i) it's not trivial, ii) we also need a script to figure out reverse dependencies for an existing installation, iii) if the installations are spread across multiple installation prefixes, we may still miss that the thing being removed is a dep for something else. Now, who's up for implementing it? ;) |
+1 I think reverse dependency tracking cannot be implemented reliably, though :) for exactly the issues you mention. |
@ebgregory has already done a reverse dependency script, I think it's sitting in a PR somewhere |
Ah, yes, I forgot about that: #1190 |
Ill try to check-in an updated version of the script next week. Im away from the office this week. -E From: Kenneth Hoste [notifications@github.com] Ah, yes, I forgot about that: #1190#1190 — Forschungszentrum Juelich GmbH Prof. Dr. Sebastian M. Schmidt |
Just checking in, to see if there are any plans on implementing this eventually. We have more and more folks using easybuild in their home directories, and their local installations override global ones. While it's easier for sysadmins who are well versed in easybuild to remove things by hand, our users don't have as much road time with easybuild. Having an option to remove software, even if it breaks dependencies, would be great. As to the missing/following dependencies, they will quickly manifest themselves thanks to the module frameworks showing problems. Thanks! |
+1 This would be helpful to have, even without dependency resolution initially. Thanks, |
For many people, including the devels, I wouldn't be surprised if this caused more problems than it would solve. Rather than make it an EB option, you could have an option like |
As the discussion seems to be coming up in the Slack again from time to time: This question keeps coming up in LUMI courses and even in our monthly "user coffee break" on LUMI, and it looks like despite all the discussion about possible problems with dependencies and so on, users would be happy if they would just have something to fully delete all traces of a single module. What our users are telling us is pretty much what @dominikborkowski said in his remark years ago. |
Is the software in question properly removed after these steps? Or are there any other traces I should delete? |
This issue might be solvable if we compare it with the idea of EasyStacks. If we assume that an EasyStack defines all the components required for certain setup, we could offer to uninstall all components not required for this stack. For example, one might add an |
If you remove a module file that is required as a dependency for something else (which may not be "in view" currently via But, I guess we could be a bit less pedantic, and just print a big fat warning that this may be the case, and maybe only actually delete without confirmation if |
'eb' should have an option to remove installed software.
The text was updated successfully, but these errors were encountered: