-
-
Notifications
You must be signed in to change notification settings - Fork 9.3k
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
Consider getting superenv from /etc/profile
and /etc/environment
#17277
Comments
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:
|
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 |
@SMillerDev Yeh, this is a good idea 👍🏻 |
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. |
Yes, I think 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 ❤️! |
Verification
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
However, from the source code I found that it's actually building a new
PATH
, with nothing from the originalPATH
, instead of removing unneeded parts from the originalPATH
.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:
So you want to include neither user-writable paths nor
PATHs
set by users. On the other hand, the system-widePATHs
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
. Withdevtoolset
installed, some admins may remove thegcc
package so the only compiler in the system will be fromdevtoolsets
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 modifyPATH
so thegcc
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 thedevtoolset
.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 itsPATH
ofsuperenv
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?
The text was updated successfully, but these errors were encountered: