Brew: Installing new package upgrades all existing ones, breaking them in the process

Created on 26 Jul 2020 · 6Comments · Source: Homebrew/brew

[Y] ran brew update and can still reproduce the problem?
[N/A] ran brew doctor, fixed all issues and can still reproduce the problem?
[Partially] ran brew config and brew doctor and included their output with your issue?

What you were trying to do (and why)

A simple brew install usbmuxd to get the iproxy command.

What happened (include command output)

Instead of just installing usbmuxd, brew insists on upgrading __all__ existing packages, even ones that have nothing to do with it. And apparently it wants to "manually" compile most of them, causing a simple one-package install to take well over 12 hours.

I cleaned up the command output so it only shows relevant pieces:

Command output



$ brew install usbmuxd

Updating Homebrew...

==> Auto-updated Homebrew!

Updated 1 tap (homebrew/core).

==> Updated Formulae

Updated 1 formula.

==> Downloading https://ftp.gnu.org/gnu/automake/automake-1.16.2.tar.xz

################################################################## 100.0%

==> Downloading https://github.com/Homebrew/formula-patches/raw/e5fbd46a25e356630592968335

==> Downloading from https://raw.githubusercontent.com/Homebrew/formula-patches/e5fbd46a25

################################################################## 100.0%

==> Downloading https://ftp.gnu.org/gnu/libtool/libtool-2.4.6.tar.xz

################################################################## 100.0%

==> Downloading https://pkgconfig.freedesktop.org/releases/pkg-config-0.29.2.tar.gz

################################################################## 100.0%

==> Downloading https://github.com/libimobiledevice/libplist/archive/2.2.0.tar.gz

==> Downloading from https://codeload.github.com/libimobiledevice/libplist/tar.gz/2.2.0

################################################################## 100.0%

==> Downloading https://github.com/libusb/libusb/releases/download/v1.0.23/libusb-1.0.23.t

==> Downloading from https://github-production-release-asset-2e65be.s3.amazonaws.com/15120

################################################################## 100.0%

==> Downloading https://github.com/libimobiledevice/libusbmuxd/archive/2.0.2.tar.gz

==> Downloading from https://codeload.github.com/libimobiledevice/libusbmuxd/tar.gz/2.0.2

################################################################## 100.0%

==> Installing dependencies for libusbmuxd: automake, libtool, pkg-config, libplist and libusb

...........

==> Upgrading 32 dependents:

autogen 5.18.12_1 -> 5.18.16_1, autogen 5.18.12_1 -> 5.18.16_1, gnupg 2.2.9 -> 2.2.21, gobject-introspection 1.56.1 -> 1.64.1_2, graphviz 2.40.1 -> 2.44.1, gst-plugins-good 1.14.2 -> 1.16.2, gst-plugins-good 1.14.2 -> 1.16.2, guile 2.2.4 -> 3.0.4, guile 2.2.4 -> 3.0.4, imagemagick 7.0.8-10 -> 7.0.10-24, libgphoto2 2.5.19 -> 2.5.25, libgphoto2 2.5.19 -> 2.5.25, libsoup 2.62.3 -> 2.70.0_1, libsoup 2.62.3 -> 2.70.0_1, libosinfo 1.2.0 -> 1.8.0_2, libosinfo 1.2.0 -> 1.8.0_2, pygobject3 3.28.3_1 -> 3.36.1, sane-backends 1.0.27_5 -> 1.0.30, spice-gtk 0.35 -> 0.37_4, spice-gtk 0.35 -> 0.37_4, spice-gtk 0.35 -> 0.37_4, usbredir 0.7.1 -> 0.8.0, vala 0.40.8 -> 0.48.7, vala 0.40.8 -> 0.48.7, jeffreywildman/virt-manager/virt-manager 1.5.1_1 -> 2.2.1_3, jeffreywildman/virt-manager/virt-manager 1.5.1_1 -> 2.2.1_3, jeffreywildman/virt-manager/virt-manager 1.5.1_1 -> 2.2.1_3, jeffreywildman/virt-manager/virt-viewer 6.0 -> 8.0, jeffreywildman/virt-manager/virt-viewer 6.0 -> 8.0, jeffreywildman/virt-manager/virt-viewer 6.0 -> 8.0, vte3 0.52.2 -> 0.60.3_1, vte3 0.52.2 -> 0.60.3_1

...........

==> Installing dependencies for autogen: coreutils, gnu-sed, libatomic_ops, bdw-gc, gmp, libffi, readline and guile@2

...........

==> Installing dependencies for gnupg: adns, gettext, libidn2, libtasn1, nettle, p11-kit, [email protected], libevent, unbound, gnutls, libgpg-error, libassuan, libgcrypt and libksba

...........

==> Installing dependencies for gobject-introspection: bison, ninja, [email protected], sqlite, xz, [email protected], meson, libpng, freetype, fontconfig, gettext, pcre, glib, lzo, pixman and cairo

...........

==> Installing dependencies for imagemagick: jpeg, libtiff, ghostscript, libde265, libxml2, itstool, docbook, docbook-xsl, gnu-getopt, xmlto, shared-mime-info, sphinx-doc, cmake, nasm, x265, libheif, liblqr, libomp, little-cms2, ilmbase, openexr, doxygen, openjpeg and webp

...........

But if you do brew info usdmuxd, you'll see:

==> Dependencies
Build: autoconf ✔, automake ✔, libtool ✔, pkg-config ✔
Required: libplist ✔, libusb ✔

__None__ of those packages do anything with e.g. gnupg and imagemagick but they were still upgraded. More importantly, the virt-manager and virt-viewer packages it wants to update don't quite work with my Python for some reason, so I don't even __want__ to upgrade those. There's also no way to force Homebrew to (re)install an older version because it always insists on using the latest. Or it simply says it cannot find the package if I append `@1.5.1` or `@1.5.1_1`. I eventually simply Ctrl+C'd the operation and am now restoring /usr/local and Homebrew information from a backup so I can at least get back to a working state. Obviously this shouldn't ever be necessary. ## What you expected to happen A package manager __should not, by default__ interact with packages the user never asked for. If a newly installed package requires an upgrade to a dependency or even an additional package, it should be confirmed by the user (unless specifically overridden with e.g. `brew install -y`). Then you can cancel the operation without leaving packages in a half-installed/configured state. Not to mention that an `install` command shouldn't __also__ include the functionality of a full `upgrade`, they're already different commands and with good reason. ## Step-by-step reproduction instructions (by running `brew` commands) * Install any new package (e.g. `brew install usbmuxd`) * Watch how Homebrew is going to update all other packages too ## Output of `brew config` and `brew doctor` commands The `doctor` command is not really relevant here, the issue at hand is more like a design problem and not something like conflicts between packages or a compatibility problem. I will however include the `config`:

HOMEBREW_VERSION: 2.4.8-136-g982d816
ORIGIN: https://github.com/Homebrew/brew
HEAD: 982d8165ae432ce40ff940bb270587ce4dfcecc4
Last commit: 13 hours ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 6e871a17749a1fe24733e088cc758ea9747c07fe
Core tap last commit: 12 hours ago
HOMEBREW_PREFIX: /usr/local
HOMEBREW_DISPLAY: /private/tmp/com.apple.launchd.irovvMC6wy/org.macosforge.xquartz:0
HOMEBREW_MAKE_JOBS: 8
CPU: octa-core 64-bit ivybridge
Homebrew Ruby: 2.6.3 => /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/bin/ruby
Clang: 8.0 build 800
Git: 2.19.0 => /usr/local/bin/git
Curl: 7.43.0 => /usr/bin/curl
Java: 11.0.3, 1.8.0_45, 1.7.0_79, 1.6.0_65-b14-468
macOS: 10.11.5-x86_64
CLT: 8.2.0.0.1.1480973914
Xcode: 8.0 => /Applications/Developer/Xcode.app/Contents/Developer
XQuartz: 2.7.8 => /opt/X11

Source

GottemHams

Most helpful comment

4. Homebrew tries to build things from source -- not sure why it does that for you.

That’s because we no longer host bottles for El Capitan.

claui on 26 Jul 2020

👍2

All 6 comments

~No idea if this helps with analysis but I saw a report with similar symptoms on Twitter earlier this week.~

Update: Those cases are likely different. In the report I linked to, brew install upgraded node for no apparent reason.

In this case though, brew install updated dependencies along with their dependents, which seems exactly what Homebrew is supposed to do.

claui on 26 Jul 2020

@GottemHams, thanks for the report!

I see several issues intermixed here:

Homebrew auto-upgrade mechanism -- @GottemHams, you can switch it off by setting HOMEBREW_NO_AUTO_UPDATE environment variable to 1.
install in cmd/install.rb calls check_installed_dependents from upgrade.rb which calls upgrade_formulae to upgrade "upgradeable" dependents.
Duplicate messages (e.g. autogen 5.18.12_1 -> 5.18.16_1, autogen 5.18.12_1 -> 5.18.16_1).
Homebrew tries to build things from source -- not sure why it does that for you.

maxim-belkin on 26 Jul 2020

4. Homebrew tries to build things from source -- not sure why it does that for you.

That’s because we no longer host bottles for El Capitan.

claui on 26 Jul 2020

👍2

Oh, I didn't notice macOS: 10.11.5-x86_64

maxim-belkin on 26 Jul 2020

Homebrew auto-upgrade mechanism -- @GottemHams, you can switch it off by setting HOMEBREW_NO_AUTO_UPDATE environment variable to 1.

Is that for updating the brew taps (equivalent of apt-get update) or does it affect the automatic upgrading of packages themselves (apt-get upgrade)? Because I'm fine with the former, it's the latter that's problematic for me (and likely others).

install in cmd/install.rb calls check_installed_dependents from upgrade.rb which calls upgrade_formulae to upgrade "upgradeable" dependents.

It's fine to check for upgradeable packages, but I'm lost as to why brew thinks imagemagick and gnupg have anything to do with usbmuxd, its direct dependencies or any dependencies of those. Because as far as I can see, nothing in the dependency chain refers to those 2 packages. It likely happens for many/all packages but these 2 are the best/clearest examples at the moment.

Or is it something like reverse/circular dependencies? Like you install a package that requires python, so it will also update python itself? Which in turn will update everything requiring python? If that's the case that's quite the undesirable behaviour.

That’s because we no longer host bottles for El Capitan.

Fair enough, I was just wondering if maybe it was a(n obsure) setting somewhere.

GottemHams on 26 Jul 2020

This is expected, though perhaps surprising, behavior.

brew install usbmuxd
usbmuxd needs pkg-config as we are building from source
pkg-config is outdated, so it gets upgraded
All reverse dependents of pkg-config get upgraded (including imagemagick)

Homebrew does not support arbitrary mixing and matching of package versions, so everything within a given package "tree" will need to be updated to the latest version as we do not test all possible combinations of versions. This is quite common behavior for package managers. In this case it's exacerbated because we no longer build binary bottles for OS X 10.11, so build dependencies will also be affected.

The messaging could better explain this, either in our documentation or at brew upgrade time, but this is not a bug in Homebrew.