QEMU dependency list growth

[omenos]

Output of brew config

HOMEBREW_VERSION: 4.5.7
ORIGIN: https://github.com/Homebrew/brew
HEAD: 6301c2d31f8dc07d2d16ddaa33711cf5a41d4e17
Last commit: 5 days ago
Branch: stable
Core tap JSON: 19 Jun 17:54 UTC
Core cask tap JSON: 19 Jun 17:54 UTC
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CASK_OPTS: []
HOMEBREW_MAKE_JOBS: 8
Homebrew Ruby: 3.4.4 => /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/3.4.4/bin/ruby
CPU: octa-core 64-bit kabylake
Clang: 14.0.3 build 1403
Git: 2.50.0 => /usr/local/bin/git
Curl: 8.7.1 => /usr/bin/curl
macOS: 13.7.6-x86_64
CLT: 15.1.0.0.1.1700200546
Xcode: 14.3

Output of brew doctor

Warning: Some installed formulae are deprecated or disabled.
You should find replacements for the following formulae:
  icu4c@76

Warning: Putting non-prefixed coreutils in your path can cause GMP builds to fail.

Warning: Homebrew's "sbin" was not found in your PATH but you have installed
formulae that put executables in /usr/local/sbin.
Consider setting your PATH for example like so:
  echo 'export PATH="/usr/local/sbin:$PATH"' >> /Users/mroche/.bash_profile

Warning: Your Xcode (14.3) is outdated.
Please update to Xcode 15.2 (or delete it).
Xcode can be updated from the App Store.

Description of issue

@leviable

I ran a typical brew upgrade today and was a bit caught off guard by the new dependency chain required by qemu. I'm assuming most of it is stemming from ffmpeg, but is this the new expected state of the package?

==> Upgrading qemu
  10.0.2 -> 10.0.2_1
==> Fetching dependencies for qemu:
brotli, giflib, highway, imath, libtiff, little-cms2,
libdeflate, openexr, webp, jpeg-xl, libvmaf, aom, freetype,
fontconfig, xorgproto, libxau, libxdmcp, libxcb, libx11,
libxext, libxrender, cairo, dav1d, faac, faad2, fdk-aac,
aribb24, frei0r, graphite2, icu4c@77, harfbuzz, lame, fribidi,
libunibreak, libass, libbluray, cjson, libmicrohttpd, mbedtls,
librist, libsoxr, libvidstab, libogg, libvorbis, libvpx,
opencore-amr, openjpeg, opus, rav1e, libsamplerate, flac,
mpg123, libsndfile, rubberband, sdl2, speex, srt, svt-av1,
leptonica, libb2, libarchive, pango, tesseract, theora, x264,
x265, xvid, libsodium, zeromq, zimg, ffmpeg, gdk-pixbuf,
graphene, dbus, libxfixes, libxi, libxtst, at-spi2-core,
gsettings-desktop-schemas, hicolor-icon-theme, libepoxy, gtk+3,
gtk4, json-glib, libnice, libshout, glib-networking, libpsl,
sqlite, libsoup, libusrsctp, orc, pkgconf, mpdecimal, expat,
python@3.13, gobject-introspection, py3cairo, pygobject3,
rtmpdump, srtp, utf8cpp, taglib, libcuefile, libreplaygain,
musepack, gstreamer, jpeg and spice-server

[gromgit]

It's because of Homebrew/homebrew-core#226935. That enabled SPICE support in qemu, at the cost of a large number of additional dependencies.

[omenos]

I totally thought I linked that PR in my original post... I always forget to proofread 😅

[leviable]

Description of issue

@leviable

I ran a typical brew upgrade today and was a bit caught off guard by the new dependency chain required by qemu. I'm assuming most of it is stemming from ffmpeg, but is this the new expected state of the package?

With --enable-spice and the spice-server dependency, yes, I believe that is the new expected state.

In the PR that enabled spice support, @carlocab did raise concern about the increased number of dependencies, and @AkihiroSuda made a suggestion around having two formulae for minimal and maximal versions of Qemu. The concern around dependency growth is certainly valid, and I'm not familiar enough with the ins and outs of Homebrew to know what the best path forward is.

My own motivations for adding spice-server and enabling spice in Qemu is that I have a use-case that can only really be solved with spice enabled Qemu. I had originally planned on just setting up a tap for my own needs, but thought this might be a good opportunity to see how the Homebrew sausage was made. I can certainly get by with a tap, and if the wider community would rather back out the --enable-spice change, I would support that.

I would say, though, that Spice does bring a lot to the table, insofar as it increases Qemu's utility and usefulness. It adds a lot to the dependency graph, sure, but it also comes with a comparable value-add.

[omenos]

It's not a problem on my end, I just wanted to make sure there wasn't some dangling dependency that pulled in the world. Doing a small dive just now this is really stemming from QEMU -> spice-server -> gstreamer.