Well, if you’re implying me based on my initial comment don’t in this case. I am not against the article per se’, but I am generally against the drive to make Fedora “be more like … pick your alternative not open sourced OS”. I have never understood the desire since Linux in general, and Fedora Linux specifically is great at going it’s own direction. Having ranted about it now enough, I say please publish.
2 Likes
OK then. Since Stephen has moved to a neutral stance and since others have expressed some support for the article, I think this article can go ahead.
Since Homebrew seems to be well-constrained to its own directory (thanks @ilikelinux for the detailed explanation of how it works), I think the following two commands would work to completely rip it out of one’s system in case of problems. (I don’t use Homebrew though. So maybe there is a better way.)
/usr/bin/find /usr/local -type l | /usr/bin/xargs -I {} /usr/bin/sh -c "if realpath '{}' | /usr/bin/grep -q '^/home/linuxbrew\b'; then /usr/bin/rm -f '{}'; fi"
/usr/bin/rm -rf /home/linuxbrew
2 Likes
@powergame: I’ve created card #83 to track the progress of your article. You can use the comments section of that card if you have further questions about getting this article to publication.
Thanks!
3 Likes
Thanks everyone for voicing your opinions. I’ll create a draft soon, and I will do my best to make it clear in the article that Hombrew is not a replacement for DNF, but it can be useful under certain circumstances. Also, I will mention how to remove the packages in case of any problems or otherwise.
For Fedora it would be useful to show the process of updating the package in brew for a new version and comparing it side by side with the same process for Fedora. Starting with the point where you realize that you need a new version of a package than it is currently available in either repository and ending up with a patch that is integrated, reviewed, built and delivered for install.
1 Like
Can anybody confirm there is a bug with brew unable to open a Firefox tab in Fedora through xdg-open?
Per my experience, Homebrew on Linux doesn’t support graphical applications (maybe yet).
The problem with opening Firefox was fixed by passing DBUS_SESSION_BUS_ADDRESS. For GUI brew apps I am not even sure which are popular on Mac to test why they don’t work with Linux.
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
I find it very worrisome that the article requests that a user invoke the HEAD commit of a shell file hosted in a non-Fedora-owned location to install the software. [1]
Is the reason Homebrew isn’t packaged in Fedora’s repository (or at least a Homebrew-official COPR) merely because of disinterest amongst packagers?
-
#!/usr/bin/env sh dnf provides brew -
Updating and loading repositories: Fedora 41 - x86_64 - Updates 100% | 3.1 MiB/s | 28.0 MiB | 00m09s RPM Fusion for Fedora 41 - Free tainted 100% | 30.9 KiB/s | 16.4 KiB | 00m01s Repositories loaded. No matches found. If searching for a file, try specifying the full path or using a wildcard prefix ("*/") at the beginning.
Additionally, I’ve noticed that the commands have become outdated with the advent of DNF5: [1] [2]
- sudo dnf groupinstall "Development Tools"
+ sudo dnf5 group install development-tools
Where should this be reported?
This is a reasonable place.
How about if I use my editorial privs to change this:
Then, install Homebrew by running the following command in a terminal:
/bin/bash -c “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)”
to something more like this?:
Then, manually examine the install.sh script, and if it appears safe,
install Homebrew by running the following command in a terminal:/bin/bash -c “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)”
I can fix that.
Thanks for you contribution to Fedora. 
1 Like
@glb, it’d be an improvement! I shan’t allow better to be the enemy of perfect. Thank you.
1 Like
I’m not involved with approving packages, but I suspect it was rejected due to its high potential for destabilizing the end user’s system.
1 Like
Ah. @glb, that appears to quite explicitly contradict what the article states:
Homebrew packages usually run as a non-sudoer user and to a dedicated prefix so they are quite unlikely to cause harm or misconfigurations.
…and would have caused me to not install it.
Yeah. I probably should have pushed back on that wording. You don’t have to be running as su to “harm” your personal data.
Also, many (most) programs run as the signed-in user. If you’ve added a great many binaries and libraries to your search path, there is an ever increasing likelihood that some program will fail because it is finding versions of those libraries and executables that it hasn’t been tested with or isn’t designed to work with. Extensive tests are run to be sure all the programs work “together” on the same system when you use the RPM/DNF package manager (or in the case of Flatpaks they are isolated from each other such that they shouldn’t interfere with each other). But when you start adding things with another package manager such as Homebrew, all those safety mechanisms are thrown out the window. 
1 Like
Considering that modifying the installation prefix is so strongly discouraged by the developers, [1] and everything that brew installs is in there, perhaps there’s a way to instruct it to not add itself to $PATH.
If so, we could always advise users to just do any work that they need brew for by opening a terminal inside that binary prefix…?
Running Homebrew apps under Toolbx would probably be the safest approach.
1 Like
@glb, thank you! That’s a superb idea. I’d say that it’s worth a mention in the article, [1] in the aforereferenced section about OS corruption mitigation. [2]
I don’t use Homebrew myself (or even Toolbox really), so I don’t want to push an untested configuration on that article. However, if you (or others) could test and confirm that such a configuration (Homebrew under Toolbox) works “well”, I’d then be willing to update the article with that recommendation.
1 Like
Blocker
@glb, shall do, when github.com/facebook/idb/issues/876 has been remediated:
Otherwise, I’ve no need for it. [1]