Should el-get check reverse-dependencies before uninstalling packages?

[DarwinAwardWinner]

Currently, I believe there is no reverse-dependency check at removal time. Do we want to prevent removing a package if another one depends on it? Do we want to offer to uninstall all dependent packages?

[dimitri]

Well, that would be good, yes.

[jleechpe]

By the same token, would we want to check and offer to uninstall any packages that are dependencies when uninstalling a package? For example when installing color-theme-desert you also install color-theme. When you remove color-theme-desert you still have color-theme installed even if you only installed it as a dependency.

I know that currently there is no distinction between packages installed as dependencies and packages installed by choice. Tracking this would start adding complexity if multiple packages all require the same dependency, however could there be a message indicating that there were dependencies that have not been uninstalled (Or a prompt offering to uninstall them once we have reverse-dependencies checked).

[DarwinAwardWinner]

Actually, there is already a distinction between manually- and automatically-installed packages. Manually-installed pacakges are listed in the user's el-get-sources, and all other installed packages are automatic. So we could definitely prompt to remove no-longer-needed automatically-installed dependencies of a package that is being uninstalled.

To get a list of manually-installed packages and their automatically-installed dependencies, we can take the intersection of the packages listed in el-get-sources with the list of installed packages, and then call el-get-dependencies on that list to bring in all of their dependencies. Then we can subtract this set of packages from the full list of installed packages to get a list of orphaned automatically-installed packages that are eligible for uninstalling.

[dimitri]

Some people are only using a single workstation and will happily M-x el-get-install and never setup an el-get-sources or such. One can even handle a bunch of package-init.el files for their own setup and have packages from the status file initialized at each Emacs startup without ever overriding the package list. So @jleechpe is right on track here, we're missing a bit of information in the status.

The current status format is very easy to accomodate to that need, though, I would think.

[jleechpe]

I would definitely say this would be a good thing to include. #720 is directly related to this.

[DarwinAwardWinner]

@deftsp made a pretty good suggestion in #720 of just warning and taking no further action for a package when el-get-init is called on that package and some of its dependencies are not installed.

[dimitri]

That is a good complementary idea, I think.

[npostavs]

just warning and taking no further action for a package when el-get-init is called on that package and some of its dependencies are not installed.

I think #1594 goes the opposite way: the uninstalled dependency will now actually be reinstalled when init'ing a package that depends on it. Maybe I was too hasty...