brew icon indicating copy to clipboard operation
brew copied to clipboard

Cannot install formulae on Linux when `$HOMEBREW_INSTALL_FROM_API` is set

Open kidonng opened this issue 1 year ago • 9 comments

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

kidonng avatar Sep 19 '22 14:09 kidonng

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.

Bo98 avatar Sep 19 '22 15:09 Bo98

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?

Rylan12 avatar Sep 20 '22 03:09 Rylan12

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.

carlocab avatar Sep 20 '22 03:09 carlocab

Because those must always be built from source (unless we're on Ubuntu 22.04)?

Rylan12 avatar Sep 20 '22 03:09 Rylan12

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.

Bo98 avatar Sep 20 '22 03:09 Bo98

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.

Bo98 avatar Sep 20 '22 03:09 Bo98

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.

Rylan12 avatar Sep 20 '22 03:09 Rylan12

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).

Bo98 avatar Sep 20 '22 03:09 Bo98

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.

Bo98 avatar Sep 20 '22 03:09 Bo98

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

github-actions[bot] avatar Oct 12 '22 00:10 github-actions[bot]