Actually, a symlink does not seem to work.
```diff
diff --git a/Formula/terminal-notifier.rb b/Formula/terminal-notifier.rb
index d147a85671..dcde0f87ec 100644
--- a/Formula/terminal-notifier.rb
+++ b/Formula/terminal-notifier.rb
@@ -22,7 +22,8 @@ class TerminalNotifier < Formula
"SYMROOT=build",
"-verbose",
"CODE_SIGN_IDENTITY="
- bin.install "build/Release/terminal-notifier"
+ prefix.install "build/Release/terminal-notifier.app"
+ bin.install_symlink prefix/"terminal-notifier.app/Contents/MacOS/terminal-notifier"
end
test do
```
```console
$ ls -l /usr/local/Cellar/terminal-notifier/2.0.0/bin/terminal-notifier
lrwxr-xr-x 1 zmwang admin 57 Nov 1 13:25 /usr/local/Cellar/terminal-notifier/2.0.0/bin/terminal-notifier -> ../terminal-notifier.app/Contents/MacOS/terminal-notifier
$ /usr/local/Cellar/terminal-notifier/2.0.0/bin/terminal-notifier -message hello
2017-11-01 13:26:52.499 terminal-notifier[21208:1735896] No Info.plist file in application bundle or no NSPrincipalClass in the Info.plist file, exiting
$ /usr/local/Cellar/terminal-notifier/2.0.0/terminal-notifier.app/Contents/MacOS/terminal-notifier -message hello # This one works.
```
Yeah, I'm afraid brew doesn't like app bundles now... I wonder if it's okay get by by installing `terminal-notifier.app/Contents/MacOS/terminal-notifier`, or if a cask migration is required.
> This will just mean basically zero or close to zero options for ffmpeg in the Homebrew mpv formula.
I think it's okay to have close to zero FFmpeg options. People who want to do funny things like `--ovc=libx265` should just build mpv themselves.
> But to be clear: if it becomes a choice between a separate mpv-ffmpeg and using libav, it's probably going to be need to be libav because maintaining yet another ffmpeg formula isn't exactly within our budgeted resources. Ahem.
Unless there's a volunteer who pledge long term support, I guess, e.g. me? I'll be happy to do that if someone demonstrates a Libav-based build is considerably worse than a FFmpeg-based build, or when I take the time to find that out myself (haven't used Libav much).
> And let's not forget that other projects like chromium or firefox also have a fixed ffmpeg in-tree.
I wouldn't complain if FFmpeg is moved into the mpv tree, and the mpv build script uses that FFmpeg out of box (possibly with a switch).
> You don't unless they're exposed separately as mpv options.
Yeah, and the problem is you don't want to stuff a bunch of FFmpeg options into the mpv formula. Now that I think about it, it's not as bad as I initially thought, since a lot of FFmpeg options are encoder options and don't affect decoding (I can't think of why you need x264, for instance), but this vendoring route is still a nightmare nevertheless.
**Update**. Just realized `mpv` could be used for encoding too, so x264 comes into play when you `--ovc=libx264`... But not sure why anyone would do that instead of using FFmpeg directly.
>> mpv-build does support FFmpeg build options
>
> It's probably a UI/UX nightmare to expose this to users though.
Yes, that's why solution 2 doesn't work.
> But none of this happens? Or do I get you wrong?
When a user does brew install mpv the formula will pull in libav and compile it (when not already there) as a build dependency (first case) or clone ffmpeg-mpv and build/link it statically on the fly (second case). The user is not required to take any action.
Again, I'm not talking about <s>a vanilla build of mpv</s> a combo of vanilla FFmpeg and vanilla mpv. That case will be fine whatever we do, except if we use Libav there *might* be more vulnerabilities (most people don't care and don't need to care anyway). But if you installed FFmpeg with options and rely on those in your mpv build, action is required; otherwise you end up with a crippled build.
Btw I'm not saying switching to Libav (hypothetically) wouldn't require user input. It would, but it's a more reasonable "Homebrew's mpv now depends on Libav, so you need to configure Libav to your liking", rather than some "we now have a special FFmpeg just for mpv" nonsense.
> A novice user that used to brew install mpv will be able to continue doing so. Just when this formula switches to libav, he will end up with less features and more security issues.
I don't think a user who installs mpv and ffmpeg without any options at all will lose features. Maybe I'm wrong, but IMO the issues we're discussing here are mostly about more advanced configurations. I can't comment on security; you're probably right there.
Btw I just looked at mpv-build and it seems ugly as hell to me. It's okay for internal build server use (you can do anything in your private space), but asking packagers to duplicate that kind of setup feels rather insane.
> It sounds like that's what mpv actually is signing up for though. No configuration of ffmpeg independently of mpv configuration.
mpv-build does support FFmpeg build options. Through
```sh
echo --enable-libx264 >> ffmpeg_options
```
You get the idea.
> Other than that, this means a --HEAD build with the current formula is broken (as no release nor HEAD or current ffmpeg builds with mpv).
I don't think it's a good idea to fix --HEAD for now.
---
Disclosure: I've never been a fan of Libav. I've been actively against Libav, since the fork.
Another v1.0.x regression: inlineStyles causing style loss for foreignObject
============================================================================
Take the same sample image as in #820:
```svg
<svg xmlns="http://www.w3.org/2000/svg" width="100" height="50">
<foreignObject width="100%" height="100%">
<style>div { color: red; }</style>
<body xmlns="http://www.w3.org/1999/xhtml"><div>hello, world</div></body>
</foreignObject>
</svg>
```
v0.7.2:
```svg
<svg xmlns="http://www.w3.org/2000/svg" width="100" height="50"><foreignObject width="100%" height="100%"><style>div{color:red}</style><body xmlns="http://www.w3.org/1999/xhtml"><div>hello, world</div></body></foreignObject></svg>
```
v1.0.1:
```svg
<svg xmlns="http://www.w3.org/2000/svg" width="100" height="50"><foreignObject width="100%" height="100%"><body xmlns="http://www.w3.org/1999/xhtml"><div color="red">hello, world</div></body></foreignObject></svg>
```
v1.0.1 `--disable=inlineStyles` (same as v0.7.2):
```svg
<svg xmlns="http://www.w3.org/2000/svg" width="100" height="50"><foreignObject width="100%" height="100%"><style>div{color:red}</style><body xmlns="http://www.w3.org/1999/xhtml"><div>hello, world</div></body></foreignObject></svg>
```
Apparently, `inlineStyles` is inlining the CSS `color` property into a `color` attribute, but HTML `div` does not support the `color` attribute.
This is just a simple case; `inlineStyles` is causing a lot of very confusing destruction to my more complex `foreignObject`s with more complex styling. `--disable=inlineStyles` fixes those cases. Maybe `inlineStyles` should be disabled altogether for `foreignObject`s?