Homebrew-core: Cannot upgrade package due to tapped dependency

[justinmayer]

I need FFmpeg installed with custom options, so I following Homebrew's suggested solution by creating and maintaining a FFmpeg with options tap:

brew tap justinmayer/tap
brew tap-pin justinmayer/tap
brew install ffmpeg

So far so good.

When I tried upgrading MPD today, it failed:

~ ➤ brew upgrade mpd
==> Upgrading 1 outdated package:
mpd 0.21.4 -> 0.21.5
==> Upgrading mpd 
==> Installing dependencies for mpd: ffmpeg
Error: ffmpeg is already installed from justinmayer/tap!
Please `brew uninstall ffmpeg` first."

I tried adding --ignore-dependencies, but that option doesn't exist for brew upgrade. (c.f. https://github.com/Homebrew/brew/issues/2345) I also tried --force, but that resulted in the same error as above.

Try as I might, I cannot find a solution for this problem. How are users supposed to resolve situations where upgrading a package fails because it insists on installing a dependency that is already tap-pin-installed?

[SMillerDev]

You'll have to maintain that package too. Homebrew can't really deal with duplicate formula like these.

[JuPlutonic]

Mb its kind of an offtopic @justinmayer
there're many options that had removed from curren mpd's formula: https://gist.github.com/JuPlutonic/736b33f0daeb24d1bb0d90511b744d33
So, would you like to add mpd to your tap.

[justinmayer]

@JuPlutonic: I don’t have a strong aversion to bundling dependencies that were previously options — my main concern is about options that have been dropped entirely and are thus no longer available. For example, I need Chromaprint and FDK AAC support in FFmpeg, but those are no longer available in Homebrew core’s version and thus only available via taps such as the one I created.

After a cursory glance at MPD’s formula and the removed options you posted, it seems to me that the only dropped options are UPnP and Last.fm support. I don’t need either of those, but if enough folks indicated that they need them and are willing to help me keep an MPD tap up-to-date via contributed pull requests, then yes, I might consider maintaining a tapped MPD formula.

[justinmayer]

@SMillerDev: Thank you for the response, Sean. Could you help me understand this better? Why is this error occurring in the first place? Homebrew is clearly aware that the dependent formula is already installed — that acknowledgement is right there in the error message. So if the dependent package is present, why throw an error? Why not just utilize what is already there?

[SMillerDev]

Homebrew has no idea that those are the same things. If you want to make a formula that is the core of your new game and it contains mostly utils you can call it coreutils in your own tap, homebrew won't care. It can only be depended on to be your game core within that tap though, in homebrew-core it means gnu coreutils.

[MikeMcQuaid]

@justinmayer We do not support using arbitrary versions of formulae from taps as dependencies from Homebrew/homebrew-core formulae as they can (and do) break in confusing, hard-to-debug ways. We should add to the tap FAQ at some point but if you want to duplicate a Homebrew/homebrew-core formula in a tap that others depend on I'd strongly recommend using a different name to avoid issues like this.

[justinmayer]

@SMillerDev / @MikeMcQuaid: Thank you for the explanations. My purpose in raising this issue, however, is a bit more bigger-picture.

When Homebrew project maintainers announced that options were no longer going to be supported, there was a significant and vocal concern among folks who use and need those options. The average response to that outcry could be summarized as, “Don’t worry — if you need options, you can simply add a tap.”

But that doesn’t make much sense if the tapped formula can’t be used in place of the formula in Homebrew core. In the case of FFmpeg, for example, there could be a multitude of formulae that depend on it, and I think it would be great if Homebrew as a project has a better answer to this than “You must then also maintain every single formula that depends on FFmpeg.”

We do not support using arbitrary versions of formulae from taps as dependencies from Homebrew/homebrew-core formulae as they can (and do) break in confusing, hard-to-debug ways.

Understandable, and I’m not insisting that Homebrew allow this. I only seek a better answer to the problem at hand, no matter what form that takes. For example, if --ignore-dependencies were a supported option when invoking brew upgrade, that would potentially solve this issue. I understand that was a low-priority item before, but with these recent changes to Homebrew, I think perhaps now is a good time to re-visit that prioritization.

Or perhaps you can think of a better proposed method for folks who understand what they are doing to use tapped formulae as dependencies? What could we do to improve Homebrew such that users don’t have to maintain entire formulae dependency trees?

[MikeMcQuaid]

Or perhaps you can think of a better proposed method for folks who understand what they are doing to use tapped formulae as dependencies? What could we do to improve Homebrew such that users don’t have to maintain entire formulae dependency trees?

I'll not reply to everything because this sums it up: I'm afraid "folks who understand what they are doing" is not a group we can trust people to self-select into and be able to fix their own issues.

The Homebrew project has asked many times for help in dealing with these issues (yes, including options) and for the community to step up and work on finding solutions to problems. In the last few years the project has literally nearly died several times due to being unable to cope with the support load. Our priority is creating and maintaining a project that works for a subset of functionality that is useful to the majority of users and trying to make it as easy as possible for people to maintain their own stuff in the Homebrew ecosystem without it impacting Homebrew/core packages in any way. I'm open to input you have on ways to improve that with the caveat that I may say "good idea, we'd accept a PR for that".