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

Uninstalling a mod should also prompt user about uninstalling its unused dependencies #978

Closed
Dazpoet opened this issue May 29, 2015 · 6 comments
Labels
Core (ckan.dll) Issues affecting the core part of CKAN Relationships Issues affecting depends, recommends, etc.

Comments

@Dazpoet
Copy link
Member

Dazpoet commented May 29, 2015

It was mentioned in the CKAN thread over at the forums that it would be pretty kickass if CKAN upon removing a mod also removed dependencies which no other mod depends on.

Say we e.g. install FerramAerospaceResearch which depends on ModuleManager and ModularFlightIntegrator. After that we install HotRockets which depends on ModuleManager and SmokeScreen.

We now have the following list of installed mods:

- FerramAerospaceResearch
- ModuleManager
- ModularFlightIntegrator
- HotRockets
- SmokeScreen

Currently if we uninstall FerramAerospaceResearch we'll end up with the following list of installed mods:

- ModuleManager
- ModularFlightIntegrator
- HotRockets
- SmokeScreen

While it seems more logical that we should end up with:

- ModuleManager
- HotRockets
- SmokeScreen

The reason for prompting the user about these things would be that e.g. uninstalling KarbonitePlus doesn't necessarily mean I want to uninstall Karbonite.

I think e.g. apt already works this way so it would seem a logical direction for CKAN to go in.

@dbent
Copy link
Member

dbent commented May 29, 2015

Arch Linux's package manager, pacman, (and presumably others) does this by keeping a bit in its database to indicate if a package was installed explicitly by the user. Then when a package is uninstalled, it will also automatically remove any dependencies that were 1) not installed explicitly and 2) are not needed by any other package.

pacman also includes functionality to:

  • Flip the explicit bit on/off
  • Control whether or not automatic removal is used
  • Perform the removal recursively (so if Mod A depends on Mod B which depends on Mod C, removing Mod A will automatically remove Mod B and Mod C, so long as neither were installed explicitly and nothing depends on them)
  • List "orphan" packages, which are packages with the explicit bit off but are currently not used by any other package.

By default I would suggest that automatic removal be used and be recursive. I would also suggest that since "explicitness" isn't currently stored that when first populating the bit, all top level packages (packages that are not dependencies for any other package) be marked as explicitly installed and all other packages be marked as being installed implicitly. This isn't perfect but good enough so long as users can toggle the explicit bit themselves.

@mgsdk mgsdk added Enhancement New features or functionality Core (ckan.dll) Issues affecting the core part of CKAN ★☆☆ labels May 30, 2015
@pjf
Copy link
Member

pjf commented May 31, 2015

+1 on dbent's comments here.

@Dazpoet
Copy link
Member Author

Dazpoet commented May 31, 2015

I like any kind of solution that makes this system work, think it would be awesome :)

@pjf pjf mentioned this issue May 31, 2015
@Dazpoet
Copy link
Member Author

Dazpoet commented Jun 8, 2015

Implementing this might accidentally provide a solution to #589 ? Or am I misunderstanding how this marking of mods explicitly installed and not would be added?

@pjf
Copy link
Member

pjf commented Jun 8, 2015

@Dazpoet : Aye, this is essentially #589 with an implementation strategy. :)

@HebaruSan
Copy link
Member

Implemented in #2753.

@Olympic1 Olympic1 removed Enhancement New features or functionality ★☆☆ labels May 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Core (ckan.dll) Issues affecting the core part of CKAN Relationships Issues affecting depends, recommends, etc.
Projects
None yet
Development

No branches or pull requests

6 participants