Brew: Why does `brew cleanup` require latest version to be installed?

[sedm0784]

I don't like to delete older versions of formulas immediately after installing new versions because experience has taught me that, very occasionally, there will be a problem with the new version and I will want to revert to the earlier version.

I like to wait at least a few days, ideally a couple of weeks before deleting the older version.

In practice, the time that I both want to run brew cleanup and remember to do so, is immediately before upgrading to the _next_ version.

However, brew cleanup does not allow me to do this:

> brew cleanup mercurial
Warning: Skipping mercurial: most recent version 3.8.3 not installed

The cleanup section of man brew doesn't mention a --force option, but I tried it just in case:

> brew cleanup --force mercurial
Warning: Skipping mercurial: most recent version 3.8.3 not installed

What is the reasoning behind disallowing the cleanup of older versions of formulas when the most recent is not installed?

Is there a simple way of removing older, inactive, versions of formulas when the most recent version is not yet installed?

(In case it isn't obvious, I'm posting this as an issue because it seems to me to be incorrect behaviour that should be fixed, but I've worded it as a question because I'm guessing there is actually a good reason the way it works as it does.)

[usmonster]

I had the same questions and opened #401 a few days ago. :) Waiting for review.

[UniqMartin]

What is the reasoning behind disallowing the cleanup of older versions of formulas when the most recent is not installed?

Technically, Homebrew doesn't consider a formula to be installed unless the latest version it knows of is installed. And because only installed formulae (in the sense I explained here) are checked for older versions that could be cleaned up, this isn't happening.

I guess for most users of Homebrew this isn't an issue, as they tend to update as soon as a new version is published. Thus, for them the brew cleanup logic behaves as expected. But I can sympathize with your use case and I think it is perfectly reasonable for cleanup to remove all but the most recent installed version of a formula, even if this version happens to be older than the latest available version.

That's not exactly an answer to your question, but to be honest I don't know why it was implemented as it is (this happened before my time with Homebrew) and I agree that this behavior is not ideal. What definitely needs to be factored into the decision is what version of a formula is currently linked into the prefix, as that one cannot be cleaned up. But I guess in your case this will always be the latest one you upgraded to (even if that's not the one Homebrew considers to be the latest).

Is there a simple way of removing older, inactive, versions of formulas when the most recent version is not yet installed?

None that I'm aware of. You'd basically had to do this manually by inspecting the “rack” of a formula, i.e. the Cellar/<formula> directory in your Homebrew prefix, and then removing the ones that are no longer needed and making sure to retain the one that is currently linked and/or pinned. Certainly not ideal.

Closing this as there's already PR #401 open to address this and I'm heading over there to provide feedback. If you have something to add to the discussion in that PR, feel free to chime in. Thanks!

[sedm0784]

Thanks for the information. I did wonder if maybe that was what was happening under the hood.

Just for pedantry's sake, I feel compelled to respond to:

I guess for most users of Homebrew this isn't an issue, as they tend to update as soon as a new version is published. Thus, for them the brew cleanup logic behaves as expected.

I also update as soon as a new version is published. It's just that I want to run brew cleanup immediately _before_ updating, rather than after, in order to ensure I can easily revert to a known-working version if I encounter problems later on.

It's super moot, though: your suggested behaviour in #401 works great for me.

[sedm0784]

The discussion in issue #401 seemed to indicate that the maintainers agreed that this was something that should be implemented, but was then closed because the person working on it ran out of steam.

Is it possible to reopen this case, or is this issue effectively dead, now (unless someone else discovers the problem independently and decides to implement it)?

N.B. I realise the above sounds passive-aggressive: it's not my intention. I'm just genuinely unclear on your process for things that you agree are issues but don't intend to work on right now. The "new issue" template suggests that only things that are actively being worked on can remain open, but if that's the case I'm not sure how you track lower-priority bugs.

[ilovezfs]

@sedm0784 please don't comment on 17 month old issues asking process questions.

[MikeMcQuaid]

is this issue effectively dead, now (unless someone else discovers the problem independently and decides to implement it)?

This is the case pretty much. We welcome pull requests on this and similar issues.

but if that's the case I'm not sure how you track lower-priority bugs.

We don't. Lower priority bugs end up sitting in the issue tracker not getting fixed so we close them. If someone cares enough to fix them: great.