Skip to content
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

Open
gribozavr opened this issue Apr 3, 2013 · 16 comments
Open

support uninstalling software + module #590

gribozavr opened this issue Apr 3, 2013 · 16 comments
Labels
Milestone

Comments

@gribozavr
Copy link
Contributor

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

@JensTimmerman
Copy link
Contributor

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
Copy link
Collaborator

+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" notifications@github.com wrote:

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


Reply to this email directly or view it on GitHubhttps://github.com//issues/590
.

@kcgthb
Copy link
Contributor

kcgthb commented Jul 3, 2014

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
Copy link
Contributor

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
Copy link
Member

boegel commented Jan 13, 2016

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
Copy link
Contributor

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
Copy link
Member

ocaisa commented Jan 13, 2016

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

@boegel
Copy link
Member

boegel commented Jan 13, 2016

Ah, yes, I forgot about that: #1190

@ebgregory
Copy link
Contributor

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]
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: #1190#1190


Reply to this email directly or view it on GitHubhttps://github.com//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


@boegel boegel modified the milestone: v2.x Jan 23, 2016
@dominikborkowski
Copy link

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
Copy link

ch741 commented Jan 25, 2019

+1

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

Thanks,
Chris

@ocaisa
Copy link
Member

ocaisa commented Jan 25, 2019

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.

@boegel boegel modified the milestones: 3.x, 4.x Feb 20, 2020
@klust
Copy link

klust commented Mar 6, 2023

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
Copy link

Turakar commented Jan 15, 2024

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
Copy link

Turakar commented Jan 15, 2024

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
Copy link
Member

boegel commented Jan 17, 2024

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.

@boegel boegel modified the milestones: 4.x, 5.0 Jan 17, 2024
@boegel boegel added the EasyBuild-5.0 EasyBuild 5.0 label Jan 17, 2024
@boegel boegel changed the title Uninstall software support uninstalling software + module Jan 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests