brew
brew copied to clipboard
Cannot install formulae on Linux when `$HOMEBREW_INSTALL_FROM_API` is set
brew config
output
HOMEBREW_VERSION: 3.6.2
ORIGIN: https://github.com/Homebrew/brew
HEAD: b8b195cc64a29595797651720ebb2ea09affb682
Last commit: 8 hours ago
Core tap: N/A
HOMEBREW_PREFIX: /home/linuxbrew/.linuxbrew
HOMEBREW_BROWSER: /vscode/bin/linux-x64/74b1f979648cc44d385a2286793c226e611f59e7/bin/helpers/browser.sh
HOMEBREW_CASK_OPTS: []
HOMEBREW_INSTALL_FROM_API: set
HOMEBREW_MAKE_JOBS: 4
Homebrew Ruby: 2.6.8 => /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.8_1/bin/ruby
CPU: quad-core 64-bit skylake
Clang: 10.0.0
Git: 2.25.1 => /bin/git
Curl: 7.68.0 => /bin/curl
Kernel: Linux 5.4.0-1090-azure x86_64 GNU/Linux
OS: Ubuntu 20.04.5 LTS (focal)
Host glibc: 2.31
/usr/bin/gcc: 9.4.0
/usr/bin/ruby: N/A
glibc: N/A
gcc@11: N/A
gcc@12: N/A
xorg: N/A
brew doctor
output
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!
Warning: "config" scripts exist outside your system or Homebrew directories.
`./configure` scripts often look for *-config scripts to determine if
software packages are installed, and which additional flags to use when
compiling and linking.
Having additional scripts in your path can confuse software installed via
Homebrew if the config script overrides a system or Homebrew-provided
script of the same name. We found the following "config" scripts:
/home/codespace/.php/current/bin/php-config
/home/codespace/.python/current/bin/python3.10-config
/home/codespace/.python/current/bin/python3-config
/home/codespace/.python/current/bin/python-config
/opt/conda/bin/python3.10-config
/opt/conda/bin/python3-config
/opt/conda/bin/ncursesw6-config
/usr/local/php/current/bin/php-config
/usr/local/python/current/bin/python3.10-config
/usr/local/python/current/bin/python3-config
/usr/local/python/current/bin/python-config
/usr/local/py-utils/bin/pylint-config
Verification
- [X] I ran
brew update
and am still able to reproduce my issue. - [X] I have resolved all warnings from
brew doctor
and that did not fix my problem.
What were you trying to do (and why)?
install a formula when $HOMEBREW_INSTALL_FROM_API
is set.
What happened (include all command output)?
https://gist.github.com/kidonng/9961307053babce8e093539063687d46
What did you expect to happen?
Formula installed succesfully.
Step-by-step reproduction instructions (by running brew
commands)
1. Ensure on Linux
2. `brew untap homebrew/core`
3. `export HOMEBREW_INSTALL_FROM_API=1`
4. `brew install neofetch`
5. See error
HOMEBREW_INSTALL_FROM_API
is not particularly supported on Linuxes older than the latest Ubuntu LTS (22.04). If you do use it, you should install your first formula without it and then switch to it. This is because Ubuntu older than 22.04 needs our glibc
and gcc@12
(which is installed automatically with the first formula you install), which have important postinstall
steps, and brew postinstall
is not supported under HOMEBREW_INSTALL_FROM_API
yet.
Though with that said, it shouldn't be failing with the error you have so we'll look into that.
Yikes, what an error!
I'm not as familiar with the Linux details so I'm not sure at first glance what's causing this. Should we blanket fail for HOMEBREW_INSTALL_FROM_API
when the linux version is not Ubuntu 22.04 or is there a way to detect which formulae would cause this?
Should we blanket fail for
HOMEBREW_INSTALL_FROM_API
when the linux version is not Ubuntu 22.04 or is there a way to detect which formulae would cause this?
We may be able to get it to work once glibc
and our preferred GCC is installed. Not sure though. If not, just blanket fail for now.
Because those must always be built from source (unless we're on Ubuntu 22.04)?
Because those must always be built from source (unless we're on Ubuntu 22.04)?
We have bottles for them (relocatable for GCC, but not relocatable for glibc), but they require postinstall to be run.
They're less broken now without postinstall than they used to be, but I still don't recommend installing them without postinstall.
In terms of the error itself however: the cause is because Formula["gcc"].aliases
appears to be returning an empty array. This is important after 66fa1f7e6aacaa84f9cc50e384a7bd8504b98a99.
We have bottles for them (relocatable for GCC, but not relocatable for glibc), but they require postinstall to be run.
They're less broken now without postinstall than they used to be, but I still don't recommend installing them without postinstall.
Do you think printing a message telling users to run the postinstall
in these cases would be enough as a temporary measure? Or would that need to happen before continuing to install any other formulae. If it's the second, a blanket failure is probably best
Looks like Formula#aliases
isn't set up to handle aliases when loaded from the API. We do have this information stored in the API, but I'm not sure what the best way to pass this along to formula classes is.
Do you think printing a message telling users to run the
postinstall
in these cases would be enough as a temporary measure? Or would that need to happen before continuing to install any other formulae.
A populated ld.so.cache
was the main thing (first couple of lines in glibc's postinstall) since that affects the linkage recording we do when we install formulae. brew
does that itself now since 66fa1f7e6aacaa84f9cc50e384a7bd8504b98a99, though only after GCC is installed. I'll need to check if the window between has any issues.
If that works, it will be ok to defer to the end since we won't be running any binaries (except ldd
for the linkage checks).
Looks like
Formula#aliases
isn't set up to handle aliases when loaded from the API. We do have this information stored in the API, but I'm not sure what the best way to pass this along to formula classes is.
Quick fix might be a simple method override when we create the formula subclass.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
Tried this on an Ubuntu 18.04 container that pulled In glibc
/gcc
here for neofetch
and: worked as expected.