Consider getting superenv from /etc/profile and /etc/environment

[RealXuChe]

Verification

• This issue's title and/or description do not reference a single formula e.g. brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.

Provide a detailed description of the proposed feature

According to https://docs.brew.sh/Formula-Cookbook#superenv-notes, when building a Formula will

removing /usr/local/bin and all user PATHs that are not essential for the build

However, from the source code I found that it's actually building a new PATH, with nothing from the original PATH, instead of removing unneeded parts from the original PATH.

The building process in the source code is basically appending four hard-coded paths, /usr/bin, /bin, /usr/sbin and /sbin, to a list of brew-specific paths.

---

I think the intention of adding the four paths here is to allow access to some binaries from the system. In the document, it says:

user PATHs are often full of stuff that breaks builds

So you want to include neither user-writable paths nor PATHs set by users. On the other hand, the system-wide PATHs set by admins can still be respected.

Unfortunately, the current approach is not perfect for accessing system-wide binaries. Admins can append to PATH by editing /etc/profile or /etc/environment, and this case can be common.

---

For example, for CentOS, it's common for admins to install Red Hat Developer Toolset, which is a set of more up-to-date toolchain from Red Hat. The toolset will be located at /opt/rh/devtoolset-<version>/ and it won't be symlinked to paths like /usr/bin. With devtoolset installed, some admins may remove the gcc package so the only compiler in the system will be from devtoolsets and there will be no compiler under /usr/bin.

Admins usually then add a source /opt/rh/devtoolset-<version>/enable line to /etc/profile. This will modify PATH so the gcc will be /opt/rh/devtoolset-<version>/root/usr/bin/gcc. By doing this, they hope that the system will have a compiler available, and the compiler is from the devtoolset.

But it's not the case for Homebrew. Since it hard-codes the four paths, it won't be able to locate the correct compiler, or even locate any compiler at all. I think for Brew on Linux, it should get its PATH of superenv from /etc/profile and /etc/environment.

Admins are supposed to know what they are doing, and for the previous example, doing so is tested and supported by Red Hat. Getting PATH from /etc/profile and /etc/environment is not only a more idiomatic and correct approach but also is not likely to break the build. If it breaks the build, it can be the admin's responsibility.

I can write code for this feature if you think this proposal is OK.

What is the motivation for the feature?

This feature allows Homebrew to work more robustly and adapt to differently-configured systems. Like the CentOS example mentioned above.

How will the feature be relevant to at least 90% of Homebrew users?

I think since most of the users are using Homebrew on Macs, not Linux, this may not be beneficial for most Mac users.

However, I believe that this may help lots of users who trying to use Homebrew on CentOS.

What alternatives to the feature have been considered?

I don't really know what to write here, maybe keep the status quo?

[MikeMcQuaid]

Admins are supposed to know what they are doing
If it breaks the build, it can be the admin's responsibility.

Sorry, this is not in keeping with our ideology or experience running Homebrew.

If we do something like this (and I'd want a bunch of @Homebrew/maintainers to approve) it would need to be:

• opt-in only using an environment variable
• flagged by brew doctor if there's any issues
• probably CentOS/Red Hat only

[SMillerDev]

Since this would only apply to gcc and curl (everything else is from Homebrew on Linux) I'd rather just check if a redhat software collection is available in addition to the usual /usr/bin/gcc check.

[MikeMcQuaid]

@SMillerDev Yeh, this is a good idea 👍🏻

[RealXuChe]

I'm sorry that this proposal does not align with Homebrew's ideology.

I still appreciate a workaround of only checking the Red Hat Developer Toolset.

Do you have any ideas on how this should be implemented? If you want, I can make a PR for this.

[MikeMcQuaid]

Do you have any ideas on how this should be implemented? If you want, I can make a PR for this.

Yes, I think locate in https://github.com/Homebrew/brew/blob/master/Library/Homebrew/extend/os/linux/development_tools.rb would be the best place to add this.

Feel free to open a PR even before it's working/done and we can help.

Closing issue just because the answer to original question is "no" and we'll talk more on PR (which we're excited about).

Thanks ❤️!