Brew: Separate build and runtime dependencies

[activatedgeek]

As of now, all Homebrew packages only have other packages as dependencies. Some packages are built on the host at the time of installation. This leads to installation of extra build dependencies which are only required for the compilation of the binary but not during the runtime.

Should such dependencies be automatically removed once the installation is complete?

Or, should the user be allowed to list and remove such build dependencies?

This issue is also posted at Homebrew/homebrew-core#3534.

CC @MikeMcQuaid

[MikeMcQuaid]

Thanks for recreating here.

[MikeMcQuaid]

Reposting my comment:

---

A good question. We don't keep track of dependencies explicitly yet (but will when we implement https://github.com/Homebrew/brew-evolution/blob/master/003-install-bottles-of-arbitrary-versions.md CC @sjackman) so for now this would be tricky. brew missing/brew doctor do the opposite to what you've said and will shout if you've removed something you shouldn't have.

As this is a feature request: would you mind refiling it on either Homebrew/brew or, ideally, write a proposal for Homebrew/brew-evolution?

Thanks!

[sjackman]

I don't think those build-time dependencies should be removed automatically, as there's a reasonably good chance that they'll be needed again in the near future. I do however think that brew cleanup could remove unused :build dependencies that were not explicitly installed by the user (and are not a :run dependency of an installed package). For that, Brew would need to keep track of which packages the user asked to be installed at the command line, and which were installed as the dependency of another package. The latter is a feature of the Debian apt-get autoremove command, which removes the requested package as well as all its unused dependencies that were not explicitly requested by the user. That would actually be a nice feature for Brew as well.

Two features here, both which require tracking why a package was installed, explicit request by user vs as a dependency of another package.

1. brew autoremove removes the requested package and any of its unneeded dependencies not explicitly requested by the user.
2. brew cleanup removes any unneeded dependencies not explicitly requested by the user.

[MikeMcQuaid]

I do however think that brew cleanup could remove unused :build dependencies that were not explicitly installed by the user (and are not a :run dependency of an installed package).

That's what I'm thinking.

brew autoremove removes the requested package and any of its unneeded dependencies not explicitly requested by the user.

I don't think we need this as a separate command if cleanup handles it.

[sjackman]

How about making this the default behaviour of brew remove? It's what I usually want to do, remove a package and its dependencies that I didn't ask for explicitly. brew remove --only foo could remove only the requested packages.

[MikeMcQuaid]

We probably can't change that interface at this time without causing alarm. brew cleanup will be fine for a first step; we can consider iterating on that in future.

[sjackman]

Sounds good.

[UniqMartin]

brew cleanup already covers a very wide range of cleanup activities. I'm not entirely sure it's wise to expand its scope even further. It's already hard to impossible to clean up the cache without also cleaning up formulae and logs or any other combination of these activities.

For the sake of compatibility, I think we could make the auto-remove behavior in brew uninstall an opt-in. E.g. brew uninstall --unused [--dry-run] could remove all no longer needed previously automatically installed formulae and brew uninstall --unused foo could be a shortcut for:

brew uninstall foo
brew uninstall --unused

[MikeMcQuaid]

Let's punt on further discussion here before we have a PR that's implementing it 😉

[ilovezfs]

Should this be closed then? I don't see much _actual_ user benefit here other than possibly basically irrelevant disk space savings. The costs of inevitable reinstalls of the same build-time only deps over and over outweighs that ten-fold unless we're adding some overwrought DSL for marking _some_ build-time deps sufficiently "common" to merit "protection" from aggressive, needless cleaning behaviors, while others are relegated to a lesser, dispensable category. Given how broken build.with? can be, I'm also pretty sure any implementation of this is just going to break user installations unless we have the fabled declarative option system.

[MikeMcQuaid]

@ilovezfs All good points but let's leave this open for now. If nothing has changed in 6-12 months on this: feel free to close in anger.

[ilovezfs]

LOL, I'm not angry :)

[MikeMcQuaid]

@ilovezfs not now but you may be in 6-12 months 😆

[ilovezfs]

Hmm I'll need to consult my :crystal_ball:

[MikeMcQuaid]

We'll accept PRs for this but we're not actively working on it at this time.

[ilovezfs]

My :crystal_ball: now shows that I will definitely not be angry about this particular issue in 6-12 months.