support uninstalling software + module

[gribozavr]

'eb' should have an option to remove installed software.

[JensTimmerman]

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. Since this is only on very rare occasions, warranted by a man made error and only a single module, we just do it by hand.

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? How do we even know when there are other packages depending on this software? Or better, the only dependencies are projects written by a user who only ever uses it in his home directory.

[fgeorgatos]

+1

and especially, this would help greatly for doing cleanup after releases (because we end up with 100s of redundant modules...) On Apr 3, 2013 5:43 PM, "Dmitri Gribenko" [email protected] wrote:

'eb' should have an option to remove installed software.

— Reply to this email directly or view it on GitHubhttps://github.com/hpcugent/easybuild-framework/issues/590 .

[kcgthb]

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.

[riccardomurri]

Why not keep it simple and just implement eb --remove as:

• load module file
• rm -rf $EBROOTXXX
• rm module file

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 ;-)

[boegel]

Yeah, that's a reasonable suggestion.

But, without --force being used, I would just issue a clear warning stating the possible problems and mentioning that EasyBuild doesn't do reverse dependency tracking yet.

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? ;)

[riccardomurri]

But, without --force being used, I would just issue a clear warning stating the possible problems and mentioning that EasyBuild doesn't do reverse dependency tracking yet.

+1

I think reverse dependency tracking cannot be implemented reliably, though :) for exactly the issues you mention.

[ocaisa]

@ebgregory has already done a reverse dependency script, I think it's sitting in a PR somewhere

[boegel]

Ah, yes, I forgot about that: https://github.com/hpcugent/easybuild-framework/pull/1190

[ebgregory]

Ill try to check-in an updated version of the script next week. Im away from the office this week.

-E

---

From: Kenneth Hoste [[email protected]] Sent: Wednesday, January 13, 2016 9:38 PM To: hpcugent/easybuild-framework Cc: Gregory, Eric Subject: Re: [easybuild-framework] Uninstall software (#590)

Ah, yes, I forgot about that: #1190https://github.com/hpcugent/easybuild-framework/pull/1190

— Reply to this email directly or view it on GitHubhttps://github.com/hpcugent/easybuild-framework/issues/590#issuecomment-171425553.

---

---

Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,

Prof. Dr. Sebastian M. Schmidt

---

[dominikborkowski]

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!

[ch741]

+1

This would be helpful to have, even without dependency resolution initially.

Thanks, Chris

[ocaisa]

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 --installation-info that just spits out the software installation directory of an easyconfig, the location of the modulefile(s) and the location of the file in the eb_repo. The user could copy/paste or script around this to remove software.

[klust]

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.

[Turakar]

Why not keep it simple and just implement eb --remove as:

* load module file

* rm -rf $EBROOTXXX

* rm module file

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 ;-)

Is the software in question properly removed after these steps? Or are there any other traces I should delete?

[Turakar]

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 --easystack-uninstall-unused option (this option would behave similar to rsync's --delete). This would provide a solution for all users using EasyStack to define all modules in a certain installation path, which might be quite common in the future.

[boegel]

Why not keep it simple and just implement eb --remove as:

* load module file

* rm -rf $EBROOTXXX

* rm module file

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 ;-)

Is the software in question properly removed after these steps? Or are there any other traces I should delete?

If you remove a module file that is required as a dependency for something else (which may not be "in view" currently via $MODULEPATH), then that module file will be broken. That's also what has been holding up implementing this.

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 --force is used.