-
-
Notifications
You must be signed in to change notification settings - Fork 9.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
macOS .pkg installer fails to detect Xcode if it's on another volume #15802
Comments
Yeah I think the error message is a bit confusing as general I/O failures will trigger that. Ideally this would would fallback to |
Hm, interesting. If it was an IO error, then why would
Sure, or even |
Yeh, I'd really like to avoid adding use of a deprecated method like this for this reason. Given the installer is a new thing: I'd rather the scope is limited and we avoid using deprecated methods. I'm leaning towards this being a WONTFIX or "the fix is updating the documentation" I'm afraid because of the workarounds of:
|
Sure, that's totally reasonable. Maybe Apple will get around to fixing things.
FWIW, my use case here was installing Homebrew in a VM with Xcode shared to it from the host. The .sh installer works fine, but I was trying to avoid installing the CLT to save disk space, and the .pkg doesn't require it. And this is probably a question for another time, but what's the current situation re: the CLT? I know that there was a switch at some point to basically require it always, even if Xcode is installed (e.g. #11250). But if the .pkg doesn't require it, perhaps that could be revisited? |
On Intel: no development tools are required at all technically, assuming you don't build from source or use If you do build from source any formula from source (including any third-party taps that don't offer bottles), CLT is actually mandatory if you aren't using the latest major macOS version, and this is enforced pretty much right away when a new major macOS is released since it ships alongside a new Xcode that removes the previous SDK unlike the CLT. The pkg installer should probably at least check for this case if it's going to enforce dev tools. Certain packages like Python, GCC and LLVM also require CLT even when installed from a bottle because they bake in a SDK path, and we always choose the CLT for that because Xcode is movable and doesn't always contain the SDKs we need. There's however an argument that we could be less restrictive about this for Python given there's many use cases for that that don't use dev tools. Certain formulae like Swift formulae may require full Xcode when building from source, but if you stay up-to-date with macOS and use the default install prefix then these cases shouldn't be an issue since you'll use the bottle. |
For comparison's sake, the |
Just for my edification, where do paths like that end up getting baked in? I've (probably accidentally - I assume I blew it away at some point for some reason and never thought about it again) been running Homebrew without the CLT for ages on this machine with no issues with bottled Python or LLVM. I'm not seeing anything in |
For GCC and LLVM it's the default sysroot. So if the CLT isn't present then it won't find any headers without a manual For Python, it'll be in some config file. Can't remember where, but it's used when building native Python modules. Should be able to be seen from a recursive grep. Won't affect all operations however.
Well given the https://github.com/Homebrew/homebrew-core/blob/149182413c1d22cfe92526bbc55067f81d51ba92/Formula/[email protected]#L27 and similar for LLVM, it couldn't have been using the bottles unless you did |
Ah-ha, that explains it. Thanks for the thorough explanation! Sorry if I lead this bug astray. I'll go with the .sh installer, though hopefully this discussion was useful for thinking about bringing the .pkg up to parity. |
Thanks for chipping in @Bo98 and for understanding @misterfifths!
@Bo98 if you can figure out how with the (very) limited APIs available: I'm definitely game.
Yeh, the temptation is to do the same here if we get other complaints.
@woodruffw did you have some ideas about being able to get rid of this one day? |
Yeah -- I began to look into this a (long) time ago with Homebrew/ruby-macho#265; I can try and revive that work, although I'm not sure yet if it'll be feasible to have a pure Ruby local codesigning implementation yet 🙂 |
if (system.compareVersions(system.version.ProductVersion, '13') < 0)
// needs CLT or something like that |
@woodruffw Looks good/interesting! I also think this would be a case where if Swift provides access to any macOS APIs for this: it could be a good option. I think it would be wonderful to have a pure-Ruby (or at least: non-CLT or Xcode) implementation if possible.
@Bo98 will give this a go 👍🏻 |
We always require it in `install.sh` and we need it for all but the latest version of macOS so this seems a simpler compromise. Fixes Homebrew#15802
brew doctor
outputVerification
brew doctor
output" above saysYour system is ready to brew.
and am still able to reproduce my issue.brew update
twice and am still able to reproduce my issue.brew install wget
. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.brew config
outputWhat were you trying to do (and why)?
Install Homebrew on macOS using the .pkg installer. This seems to reproduce on the latest versions of Monterey and Ventura, as well as beta 4 of Sonoma.
What happened (include all command output)?
The
fileExistsAtPath
call ininstallation-check
script in Distribution.xml fails if the path is on another volume. In my case, /Applications/Xcode.app was a symlink to another volume (and I didn't have the CLTs installed), so the installer was convinced that it couldn't proceed.This output is generated in /private/var/log/install.log:
Adding that option to the Distribution.xml file does indeed fix the issue, but it results in this ominous warning from
productbuild
:I believe that this is an Apple bug.
allow-external-scripts
as documented has nothing to do with checking file existence, only running arbitrary executables through the JS interface. I filed FB12823044 with Apple.In the meantime, perhaps adding
allow-external-scripts
is an option? I'm not sure if Apple is actually rejecting such packages at notarization time. On the other hand, maybe this is too niche of a circumstance to worry about.What did you expect to happen?
The installer should detect an Xcode or CLT install even if it's a symlink to another volume.
Step-by-step reproduction instructions (by running
brew
commands)(Alternatively you could symlink /Library/Developer/CommandLineTools to another volume instead of Xcode.app. Or just the
git
file that the script is checking. Any path that winds up on another volume seems to trigger this error.)The text was updated successfully, but these errors were encountered: