Why is it so hard to install old versions of homebrew-core packages?

[tyteen4a03]

Title. You can't brew install <old commit formula.rb file> because that's been disabled, you can't extract formulas to homebrew/core. What am I supposed to do? I know the version I want, it's there in commit history yet I can't get to it because it's not listed as an official version on the formula page.

EDIT: To anybody who has come to this page, use this script: https://github.com/orgs/Homebrew/discussions/155#discussioncomment-7711498

[SMillerDev]

Why is it so hard to install old versions of homebrew-core packages?

Because we don't support it and generally advise against it.

you can't extract formulas to homebrew/core

The point of extract is essentially that you're assuming responsibility of maintenance for that version of the formula. Moving that responsibility from homebrew/core to homebrew/core is pointless. The proper way is to make your own tap where you maintain whatever formula you need. https://docs.brew.sh/Manpage#tap-new-options-userrepo will help you get started.

[SMillerDev]

I think this is the gist of the issue: You think of the formulas as software, many of us think of them as dependencies.

They are software, you're confusing homebrew with an application level package manager: https://en.wikipedia.org/wiki/List_of_software_package_management_systems while they really aren't the same thing.

[iMichka]

The philosophy of Homebrew is that we do not care that much about old versions of software. This is how Homebrew was designed, and how it has worked for the last 10 years.

Some people confuse Homebrew with virtualenvs / conda / nix, which surely provide a better support for older versions and different build environments. We are not doing this and do not plan to do this in a foreseable future. Our audience is also not the same.

But support for old versions is not totally zero in Homebrew: you can host an old formula in a tap if you want to maintain it, or we have some versioned formuale (example python@3.8 and python@3.7), because we thought these were really important and deserved to be maintained by us. But we try to avoid too many of these and there are strict rules around versioned formulae.

So it is totally doable to build your own collection of homebrew formulae for your company. We even introduced the possibility to build bottles and host them yourself (for free) a few days/weeks ago: https://brew.sh/2020/11/18/homebrew-tap-with-bottles-uploaded-to-github-releases/.

[KJTsanaktsidis]

The lack of this functionality (and, indeed, the fact that it was removed) is incredibly frustrating. This doesn't just affect "companies using old unmaintained software" or "people using brew as a language package manager" either; it affects the people you're referring to as "users" as well.

Today I hit a straight-up regression in a new version of Virtualbox after doing a brew upgrade. The version from three days ago in homebrew/homebrew-cask doesn't have the regression. I want to install an old version of Virtualbox today, so that I can carry on with what I wanted to do, and then go and upgrade it back to the latest version in a few days when this regression is presumably fixed. The idea of using brew extract and a custom tap that will exist for like half a week is incredibly clunky.

[SMillerDev]

Two things regarding your comment.

1. VirtualBox is a cask and there is a cask-versions repository with older cask versions.
2. If a regression is found and upstream yanks a version, we will revert to the latest published version if requested. We just won't be publishing versions that upstream doesn't support.

[jzwolak]

A library is a dependency. Many of the formulas in Homebrew are libraries... maybe even most.

Grails, to name one example, is a framework and absolutely needs to be pegged at a specific version! It's a formula in Homebrew.

Homebrew claims to be the "missing package manager"... most package managers I know of on Unix based systems allow selection of versions... specifically for the cases of problems with security and compatibility. If a new version has a critical security hole, reverting to the previous version may be the quickest way to secure a system. If a new version breaks something - like the development work flow I'm using that depends on all the development tools installed via Homebrew - then reverting to the previous version is the quickest solution until a longer term fix can be implemented.

[tyteen4a03]

If anybody is Googling this after me, here is what I did (since this doesn't seem to be documented coherently anywhere):

brew uninstall <package> # Note 0
brew tap-new <yourname>/<package> # Note 1
brew extract --version <version_you_want> composer <yourname>/<package> # Note 2
brew install <package>@<version>
brew pin <package>@<version> # Note 3

[0] You probably want to do this, just to get brew link working nicely.

[1] This creates a new Tap, which is a Git repo. Apparently homebrew also expects you to publish these taps so it automatically adds an upstream to https://github.com/<yourname>/<package>; if you don't you will get fatal: Could not read from remote repository. while running brew install <package>@<version> but is perfectly safe to ignore.

2022 UPDATE: Creating a GitHub repository now seems mandatory. It now asks for my GitHub login details.

[2] The easiest way to find this is by going through the history page on GitHub: https://github.com/Homebrew/homebrew-core/commits/master/Formula/<yourpackage>.rb

[3] This is not necessary since this formula has been extracted and will never get updated (unless you brew extract again), but I like to do it because it makes me feel safe.

[gromgit]

You don't need to use arch -arm64 in the general case. I was merely pointing out to @GeorgeLambadas that he'd gotten the CPU argument wrong.

[SourceNode]

I am on an M1 MacBook Pro, so I do need to specify this option. I just don’t understand which command needs it or how to set my brew environment.

[gromgit]

Homebrew will tell you if it's needed and how to do it:

Rosetta$ brew install hello
Error: Cannot install under Rosetta 2 in ARM default prefix (/opt/homebrew)!
To rerun under ARM use:
    arch -arm64 brew install ...
To install under x86_64, install Homebrew into /usr/local.

If you don't see the above text, you shouldn't use arch -arm64.

[al42and]

2022 UPDATE: Creating a GitHub repository now seems mandatory. It now asks for my GitHub login details.

brew tap-new --no-git abc/def works for me

[thesuperzapper]

It seems that brew extract removes the bottles from the .rb file, so you will always be building from source.

Which pretty much means the only solution left is to download the <formula>.rb file from the Homebrew/homebrew-core repo (at the commit for the version you want), and then run brew install ./<formula>.rb.

Because it is very tedious to find the old <formula>.rb files, I made a script to do it, see my other answer: https://github.com/orgs/Homebrew/discussions/155#discussioncomment-7711498

[tresf]

I greatly empathize with the OP. The Homebrew team seems to have many justified reasons for removing this functionality (and rarely get the credit deserved for maintaining > 5,000 core formula as well as a robust automated build infrastructure), but there are also several controlled use-cases to either stick to an old .rb URL , or whip up a quick .rb gist for a proof-of concept. For example, my colleague was working on a patch for openjdk upstream, and a .rb gist was a nice stop-gap for using Homebrew's reliable build system (e.g. swap the url) to build his changes locally. I'm sure this is abuse of the way Homebrew is intended to be used, but it's very convenient and I too am sad to see this feature is gone. I've switched to brew tap as instructed and it's working quite easily (and in the long run probably encourages more PRs) so it's a moot point, but I wanted to chime in in-support of the OPs concerns. There's something rather elegant and productive about whipping up a quick proof-of-concept gist. It will be sorely missed.

[hexsel]

Additionally, a lot of software is simply not backwards-compatible enough, and although we intended to use homebrew to manage the development environments, not being able to pick the same version for everyone is a bit of a bummer (as in, makes it inviable).

Having said that, I empathize with the developers, and I wish there was more support from corporations for this type of work.

[gagarine]

Primary reason I mostly use MacPort. If you can install a specific version once, you will be able to install it in the future. And if port do fail to install one things, 99% of the time it's your fault and you will be able to reproduce the problem.

For maximum packages list, joke about beer, cool website and minimal dependencies download use Homebrew.
For stability, fast and well made command line, safe default (admin password are useful, /opt too) and reproducibility use MacPort.

[jiasli]

Python 3.9.8 has serious regression (Azure/azure-cli#20322, Azure/azure-cli#20269, https://bugs.python.org/issue45235), but there is no easy way to install Python 3.9.7 with brew.

[jiasli]

@SMillerDev, thanks for the explanation. The following may not be related, so please feel free to transfer to a new issue:

I installed brew in a debian docker container:

docker run -it --rm debian

apt update
apt install curl git build-essential --yes
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"' >> /root/.profile
eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"

git config --global user.email "you@example.com"
git config --global user.name "Your Name"
brew tap-new my/python
brew extract --version 3.9.7 python my/python

The brew extract command gave error:

==> Searching repository history
Error: python: undefined method `[]' for nil:NilClass

Is anything I am doing wrong?

[carlocab]

Try brew extract --version 3.9.7 python@3.9 my/python.

[jiasli]

That works!! I can now install with

brew install gcc
brew install python@3.9.7

I thought python works because I saw:

https://formulae.brew.sh/formula/python@3.9

python@3.9
Also known as: python, python3, python@3

But after installation, now I got

==> Summary
🍺  /home/linuxbrew/.linuxbrew/Cellar/python@3.9.7/3.9.7_1: 7,412 files, 141.2MB, built in 8 minutes 58 seconds
==> No outdated dependents to upgrade!
==> Checking for dependents of upgraded formulae...
==> Reinstalling 1 broken dependent from source:
my/python/python@3.9.7
==> Caveats
==> python@3.9.7
Python has been installed as
  /home/linuxbrew/.linuxbrew/bin/python3

Unversioned symlinks `python`, `python-config`, `pip` etc. pointing to
`python3`, `python3-config`, `pip3` etc., respectively, have been installed into
  /home/linuxbrew/.linuxbrew/opt/python@3.9.7/libexec/bin

You can install Python packages with
  pip3 install <package>
They will install into the site-package directory
  /home/linuxbrew/.linuxbrew/lib/python3.9/site-packages

tkinter is no longer included with this formula, but it is available separately:
  brew install python-tk@3.9

See: https://docs.brew.sh/Homebrew-and-Python

root@03db84c670e0:/# /home/linuxbrew/.linuxbrew/bin/python3
bash: /home/linuxbrew/.linuxbrew/bin/python3: No such file or directory

root@03db84c670e0:/# /home/linuxbrew/.linuxbrew/Cellar/python\@3.9.7/3.9.7_1.reinstall/bin/python3.9
/home/linuxbrew/.linuxbrew/Cellar/python@3.9.7/3.9.7_1.reinstall/bin/python3.9: error while loading shared libraries: libpython3.9.so.1.0: cannot open shared object file: No such file or directory

[carlocab]

I've seen that before, but I have no idea what causes it. Try doing

brew uninstall python@3.9.7
rm -rf "$(brew --cellar)/python@3.9.7"
brew install python@3.9.7

[jiasli]

Reinstalling does fix the problem, though I can't understand why. 😅

Here is my full script:

docker run -it --rm debian

apt update
apt install curl git build-essential --yes
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"' >> /root/.profile
eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"

git config --global user.email "you@example.com"
git config --global user.name "Your Name"
brew tap-new my/python
brew extract --version 3.9.7 python@3.9 my/python

brew install gcc

brew install python@3.9.7
brew uninstall python@3.9.7
brew install python@3.9.7

BTW, Python 3.9.9 has been released: https://www.python.org/downloads/release/python-399/. Homebrew can take it now.

[jiasli]

For what it's worth, one of our users found another smart way to install old versions (Azure/azure-cli#20211 (comment)):

curl https://raw.githubusercontent.com/Homebrew/homebrew-core/7607de411f8ac0ad926ff2caadf8a9abf713cec8/Formula/azure-cli.rb > $(find $(brew --repository) -name azure-cli.rb) && brew reinstall azure-cli

The removal of brew install <old commit formula.rb file> does cause inconvenience and make installing old versions cumbersome.

[SMillerDev]

This will also cause you to miss any updates released after, because you have modifications to the formula, while brew extract doesn't.

[carlocab]

It's also a bit fragile, and can cause brew update issues down the line.

[2a5A1Ghu1]

Using extract for flutter just ends up in an error
"Error: Could not find flutter! The formula or version may not have existed."

I have tried several versions.

Crippling downloading older versions of anything has messed up my workflow so many times, especially with cryptocurrency projects that still (annoyingly) use openssl 1.0.1, I might just have to abandon brew completely sadly. I literally have been keeping VM's of older OS's with older versions of brew as a work around just to keep my work flow going.

I mostly used brew to install prerequisites easily, I don't mind building from source, if building from source could be the default feature for really old stuff that would be nice. Could even have a big fat warning that legacy is not directly supported.

Oddly some old formulas remain such as berkeley-db@4, wonder if that has to do with bitcoin...

[SMillerDev]

You do realize that flutter is just a folder to be downloaded and added to your path.

That's because it's a pre-compiled program. Which is a cask in homebrew terms.

My point was that "brew extract" can't even find flutter at all even though it is available via brew install.

Because it's a cask and it was never designed to support those because they are dependent on a generally more unreliable source.

[gromgit]

I wouldn't even expect them to be maintained. but being able to pull the source and the prerequisites to compile them from scratch would be nice. If there is a URL issue the older source can easily be found and entered manually, this rarely happens though.

That requires a formula (a Homebrew recipe that starts with upstream source code and downloads / builds / installs / creates binary bottles), not a cask (a Homebrew recipe that starts with upstream binaries and downloads / installs them).

That's why wireshark-the-formula and wireshark-the-cask look so different.

That's why I also said that to get what you're asking, someone has to write the flutter formula. The last time someone tried that, they started with the upstream binaries, which is a no-no -- those are far likelier to be deleted upstream when newer versions are released, making brew extract useless.

You do realize that flutter is just a folder to be downloaded and added to your path.

The upstream all-on-one package may be such, but the underlying source code is spread across several repos, so it's definitely not that simple to get a proper formula done.

[KJTsanaktsidis]

cryptocurrency projects that still (annoyingly) use openssl 1.0.1

Great, don't even need to wait for the crypto devs to scam you with this one, the hackers get you first!

[2a5A1Ghu1]

True, but you still need to build the old stuff so you can upgrade them. I'm not just a crypto dev... Flutter isn't usually used in crypto. Also, I just hit another wall, because it is nearly impossible to build older versions even from source I can't build an older version of arangodb which needs to be done because the current release will not build on mac arm64 processors due an SSE4 incompatibility. It is even recommended by the arrango devs to build an older version on mac arm until a fix can be made. Building older versions of libs is one of the most searched things for brew. Not sure why the brew team has to be so aggressive about this but it's lame and really messing things up for a lot of people. Like I said before, retaining the bottles is not needed but being able to at least build from source would be a nice option. Crap I will even take just a list of all the needed prerequisites to get something built that isn't supported anymore.

I can download, run Ubuntu 14 and install pretty much all of it's antiquated libs at my pleasure. Not sure why it's different here.

[SMillerDev]

it is nearly impossible to build older versions even from source

That's probably worth a different discussion since it's a completely different issue.

I can download, run Ubuntu 14 and install pretty much all of it's antiquated libs at my pleasure. Not sure why it's different here.

Because homebrew is on a rolling release model, try doing an older Arch install and you'll find that it doesn't work either.

[sriram0601]

Hi, I am using RMagick 4.2.2 gem in my project which uses ImageMagick 7.1.0. Now I have updated the ImageMagick to 7.1.1-11. Now I can't install the older version of ImageMagick using the brew commands.

[2a5A1Ghu1]

They don't care, "it's a rolling release model", based on apples latest(os) supported machines I assume. Your best bet is to make a vm and install the oldest os that brew sort of supports, sync with the oldest github version of brew you can sync with and then disable all the auto updates.

Best thing you can do is if you want to run older software of any type never ever update brew, any of the packages or install an alternative like pkgsrc or macports. My 2011 macbook pro is still happily being my work horse with these options.

[osalbahr]

You can rollback the formula using the commit history and install it from source.

[2a5A1Ghu1]

Doesn't work if you have a new version of brew installed as the formulas are incompatible with the new formula schema. You would have to create a new formula or roll back brew completely which can break other things. Installing old formulas use to be relatively simple until a few years ago. I understand that the brew team has to respect github limitations but at least being able to get a formula to just compile the old stuff would be nice. The brew team does great work but they still seem like they don't care.

[MikeMcQuaid]

The brew team does great work but they still seem like they don't care.

It's not that they don't care as much as they are lacking the time and resources to support what you'd like here and no-one plausible and reliable has stepped up to volunteer to do that work indefinitely.

[thesuperzapper]

EDIT: This approach does not always work, because some formulas are not updated by PR. However, I have made a generic script.

See new answer: https://github.com/orgs/Homebrew/discussions/155#discussioncomment-7711498

---

Original answer:

After much pain, I think this is the only way to install old brew packages, as of November 2023.

(The old brew extract method seems to no longer use the pre-built bottles, so will always build from source).

Step 1:

First, we need to find the pull request that created the version we want to use.

Luckily, brew has a command called brew search:

brew search --closed --pull-request FORMULA_NAME@FORMULA_VERSION

For example, with argocd and version 2.8.6:

brew search --closed --pull-request argocd@2.8.6
# ==> Closed pull requests
# argocd 2.8.6 (https://github.com/Homebrew/homebrew-core/pull/153078)

Step 2:

Now we need to get the raw GitHub URL for the .rb formula file.

Step 2a:

Open the PR link from step 1, and scroll down until you find something that looks like this:

Step 2b:

Look for the file ending in .rb that changed in that commit, and click its right-hand ..., followed by view file:

Step 2c:

Click on the "raw" button on the .rb file, and copy the URL from your browser:

Step 3:

Now that we have the URL we can download it and use brew install, which should use the pre-built bottles (assuming they are still present on the Homebrew OCI repo).

# for example, this is the URL for version `2.8.6` of `argocd`
wget https://raw.githubusercontent.com/Homebrew/homebrew-core/67082a334f219440f90dd221ad939d0ef6756409/Formula/a/argocd.rb

# remove any existing version
brew remove argocd

# install from the local formula
brew install ./argocd.rb

# pin the version to prevent `brew upgrade`
brew pin argocd

[MikeMcQuaid]

Note: this approach has a lot of problems:

• the usage of brew pin here will prevent anything depending on this package from every being upgraded, either
• you will never get any security updates for this package or its descendents
• this formula will be very likely to end up broken in future versions of macOS and/or Homebrew and there's no way of fixing a static URL like this
• it's unsupported by Homebrew and is likely to break in future versions

[tyteen4a03]

Yes, we are aware that it will break things. Yes, we are aware we will not get security updates. But sometimes circumstances mean we have no choice but to install that specific version of a specific dependency. That's the entire point of this thread, and I'm sad that Homebrew maintainers don't understand where we are coming from - given the upvotes in this thread, I am far from alone.

[MikeMcQuaid]

We definitely understand where you are coming from. I'm just pointing out the risks of this approach to anyone who comes along to this thread and follows these instructions with those in mind.

There's always a choice, here. This is a quick and easy solution but it is not one that we are willing or able to support and, particularly if you're in a commercial environment, will expose you to security risks that we need to make you aware of.

[thesuperzapper]

What's great about the above approach is that every time the user runs brew upgrade it will warn them that they are running old package versions, so they can make an informed decision about the implications of choosing not to upgrade.

But in many situations, the user won't have much of a choice, as they would only do this if something was broken/incompatible in the latest version of their package.

[thesuperzapper]

@huyz @tyteen4a03 I have made a cool script to automate this, see https://github.com/orgs/Homebrew/discussions/155#discussioncomment-7711498

[thesuperzapper]

I have made a brew-switch function that you can add to your ~/.zshrc that will download any version of any core formula.

It works by:

1. searching commits in the Homebrew/homebrew-core repo for the most recent one that contains the name of your formula and the requested version
2. downloading the <formula>.rb file from that commit
3. using brew install ./<formula>.rb to install the file locally
4. running brew pin <formula> to stop brew upgrade from messing with it

Usage

The general usage is:

brew-switch <formula> <version>

For example, to install version 2.8.6 of the argocd formula:

brew-switch argocd 2.8.6

Install

1. Dependencies

# install github command line
brew install gh

# authenticate with your github account
gh auth login

2. Add brew-switch to .zshrc

Open your ~/.zshrc file, and add the brew-switch function.

For example, if you like vim:

## don't forget to close and reopen your terminal after changing
vim ~/.zshrc

Add these lines to the end of the file:

# a script to install a specific version of a formula from homebrew-core
# USAGE: brew-switch <formula> <version>
function brew-switch {
  local _formula=$1
  local _version=$2

  # fail for missing arguments
  if [[ -z "$_formula" || -z "$_version" ]]; then
    echo "USAGE: brew-switch <formula> <version>"
    return 1
  fi

  # ensure 'gh' is installed
  if [[ -z "$(command -v gh)" ]]; then
    echo ">>> ERROR: 'gh' must be installed to run this script"
    return 1
  fi

  # find the newest commit for the given formula and version
  # NOTE: we get the URL, rather than the SHA, because sometimes the commit belongs to an older repo
  local _commit_url=$(
    gh search commits \
      --owner "Homebrew" \
      --repo "homebrew-core" \
      --limit 1 \
      --sort "committer-date" \
      --order "desc" \
      --json "url" \
      --jq ".[0].url" \
      "\"${_formula}\" \"${_version}\""
  )

  # fail if no commit was found
  if [[ -z "$_commit_url" ]]; then
    echo "ERROR: No commit found for ${_formula}@${_version}"
    return 1
  else
    echo "INFO: Found commit ${_commit_url} for ${_formula}@${_version}"
  fi

  # get the 'raw.githubusercontent.com' URL from the commit URL
  local _raw_url_base=$(
    echo "$_commit_url" |
    sed -E 's|github.com/([^/]+)/([^/]+)/commit/(.*)|raw.githubusercontent.com/\1/\2/\3|'
  )

  local _formula_path="/tmp/${_formula}.rb"

  # download the formula file from the commit
  echo ""
  local _repo_path="Formula/${_formula:0:1}/${_formula}.rb"
  local _raw_url="${_raw_url_base}/${_repo_path}"
  echo "INFO: Downloading ${_raw_url}"
  if ! curl -fL "$_raw_url" -o "$_formula_path"; then
    echo "WARNING: Download failed, trying OLD formula path"
    echo ""
    _repo_path="Formula/${_formula}.rb"
    _raw_url="${_raw_url_base}/${_repo_path}"
    echo "INFO: Downloading ${_raw_url}"
    if ! curl -fL "$_raw_url" -o "$_formula_path"; then
      echo "WARNING: Download failed, trying ANCIENT formula path"
      echo ""
      _repo_path="/Library/Formula/${_formula}.rb"
      _raw_url="${_raw_url_base}/${_repo_path}"
      echo "INFO: Downloading ${_raw_url}"
      if ! curl -fL "$_raw_url" -o "$_formula_path"; then
        echo "ERROR: Failed to download ${_formula} from ${_raw_url}"
        return 1
      fi
    fi
  fi

  # if the formula is already installed, uninstall it
  if brew ls --versions "$_formula" >/dev/null; then
    echo ""
    echo "WARNING: '$_formula' already installed, do you want to uninstall it? [y/N]"
    local _reply=$(bash -c "read -n 1 -r && echo \$REPLY")
    echo ""
    if [[ $_reply =~ ^[Yy]$ ]]; then
      echo "INFO: Uninstalling '$_formula'"
      brew unpin "$_formula"
      if ! brew uninstall "$_formula"; then
        echo "ERROR: Failed to uninstall '$_formula'"
        return 1
      fi
    else
      echo "ERROR: '$_formula' is already installed, aborting"
      return 1
    fi
  fi

  # install the downloaded formula
  echo "INFO: Installing ${_formula}@${_version} from local file: $_formula_path"
  brew install --formula "$_formula_path"
  brew pin "$_formula"
}

[MikeMcQuaid]

Because Homebrew does not have a "version" concept for dependencies
all it knows to do is install the latest versions

These statements are not correct. Homebrew will allow the oldest version of dependencies that are known to work. These are tracked correctly. A script like this is extremely likely to break that and cause things to fail in ways we don't support.

If this script becomes a common source of problems/issues for Homebrew maintainers: expect us to break it on purpose, sorry.

[thesuperzapper]

These statements are not correct. Homebrew will allow the oldest version of dependencies that are known to work. These are tracked correctly. A script like this is extremely likely to break that and cause things to fail in ways we don't support.

If this script becomes a common source of problems/issues for Homebrew maintainers: expect us to break it on purpose, sorry.

@MikeMcQuaid thanks for confirming my suspicions that you are breaking this functionality on purpose.

In light of this, I believe the community needs to have a serious discussion about whether Homebrew is the right place to distribute anything that could require the user to download a specific version.

I will keep updating this script as long as Homebrew remains relevant (but I have designed it such that breaking it will require significantly reducing the functionality of Homebrew).

As a software developer and maintainer of many open-source tools myself, it is often critical that I am able to downgrade CLIs and other apps (which often don't even depend on other packages).

I am going to make one more impassioned plea to treat your users like adults (who are mostly software developers themselves) and re-introduce the brew switch functionality directly in Homebrew. Feel free to make using it a pain to use, and noisy with warnings. But its an important safety feature for users and package maintainers who trust Homebrew to distribute packages to their users.

[MikeMcQuaid]

@MikeMcQuaid thanks for confirming my suspicions that you are breaking this functionality on purpose.

We have previously only done this in cases where we are deluged with issues from people who do not read the messages that Homebrew itself output saying "this will not work, do not file issues about this". Blame those people, not us. All I'm saying here is: if the same result happens here: we'll need to do the same thing again. I hope it doesn't, to be clear; I take no pleasure in it but we're a volunteer run project that's chronically understaffed to handle the number of users we have.

In light of this, I believe the community needs to have a serious discussion about whether Homebrew is the right place to distribute anything that could require the user to download a specific version.

The correct, stable, reliable way to rely on a specific version is to maintain that version by itself in a tap. If it's in homebrew/core: you need to brew extract it. Is this as easy as your solution? No. Is it more reliable, reproducible and robust? 100%.

Homebrew's binary packages are not resilient to underlying OS changes in the ways you would like them to be. If they were: we'd be leaning in this direction more, too.

We are not interested in providing features that only reliably work for some people some of the time. When they break: they become our problem to deal with.

I am going to make one more impassioned plea to treat your users like adults (who are mostly software developers themselves) and re-introduce the brew switch functionality directly in Homebrew. Feel free to make using it a pain to use, and noisy with warnings. But it's an important safety feature for users and package maintainers who trust Homebrew to distribute packages to their users.

Look, I've been maintaining this project almost entirely in my free time for over 14 years now. It doesn't matter if most users are mostly adults and mostly software developers: Homebrew now has enough users that a tiny percentage of users repeatedly reporting or commenting on the same issues again and again quickly drowns out our small number of maintainers ability to get anything meaningful done on this project. While you may have preferred how Homebrew was in those days: it sucked to be a maintainer then, a bunch of them burned out and the project on several occasions came much closer than you'd have guessed from the outside to falling over and dying entirely.

This is no longer the case. We're in a good place now. Things are sustainable, maintainers are happy. This is the result of both the maintainers within the project and the project itself having clearer, firmer boundaries on what we can do well and what we cannot.

Folks like yourself can push against those lines with these sorts of tools. That's fine and encouraged: I'm just putting out a warning that when this ceases to be sustainable for the project, we'll do what we need to do to make things better.

It seems like I'm not hearing, appreciating or listening to your feedback: I am and do and am personally working on solutions to some of these problems, they are just not all likely to exist entirely within Homebrew itself.

[huyhandes]

I my case the openvpn 2.5.8 have to use a commit patch instead of bottle version, so I suggest add an optional github raw url

[fadillicious]

thank @thesuperzapper, you save my time 🥂

[osalbahr]

Would a brew revert to undo the last brew upgrade be a plausible middle-ground? The issue seems to be more about when an upgrade breaks something in the user’s workflow rather than wanting to install an arbitrary old version per se.

[MikeMcQuaid]

@osalbahr Yes, that's a good idea.

[2a5A1Ghu1]

Guys, they will never support the ability to at least get and compile older libs nor even list the required deps for said libs so one can compile them themselves. They strictly follow Apples EOL. I have slowly moved to https://www.pkgsrc.org so I can compile on my older machines as they archive their older releases without bashing you over the head to update. As much as a love homebrew, I am having to leave as it just breaks everything near an EOL. Just move on, there is no reason to even argue, they are not going to do anything about it. They won't even package up old versions for download, it's difficult to maintain something once your to deep in the rabbit hole.

[osalbahr]

If you would like to go down the compile-everything-from-source route, Spack might be more of your interest. It automates it for you and allows arbitrary version pinning and the UI is very similar to Homebrew.

And of course, there’s also Nix with a bit of a learning curve.

[MikeMcQuaid]

We do package old versions that meet these requirements: https://docs.brew.sh/Versions