Article Summary: I like to write an article about installing Homebrew on Fedora and how it can be used to easily install CLI applications.
Article Description:
The article will be about Homebrew, what it is, how it can be installed and what it can do, on Fedora to ease the life of developers looking to easily install and manage applications and packages like Python, FFMPEG, Kubernetes on Fedora without root access.
Let me know what you think and I can come up with a quick draft in a few days.
Homebrew is a package manager for both macOS and Linux. It was originally meant to be the de facto package manager for macOS, which uses image-based upgrades, but also works on most flavors of Linux.
Hi Steven, I used to use it on Mac, and they called it Linuxbrew but they recently changed the Linux version’s name also to Homebrew. A short while ago I learnt after trying that it also works well on my Fedora too. It’s really easy to install and can be a good complement to dnf to install software like minikube, etc easily without having to manually grab and install the binary and without using sudo.
Is there any overlap between the software packages that can be installed with Homebrew and the packages that can be installed with DNF? If so, we probably want people to stick with DNF when using Fedora Linux to take advantage of some of the distro-specific optimizations (e.g. RPMCoW which is slated for Fedora Linux 36).
Hi Gregory. There can be overlaps, yes for example ffmpeg. But, some binaries are not available as rpm for example Minikube. In this case, homebrew can be really handy to install and update Minikube.
Where does Homebrew install packages and how does it manage the search path? If I have something installed with both Homebrew and DNF, which one will execute?
It installs packages to /home/linuxbrew/.linuxbrew and changes the ownership of that folder to the current user, so that the current user can install applications without sudo. It also updates PATH in ~/.bash_profile to make the newly installed app available in terminal.
Regarding your question, which one will be executed if a piece of software is both installed via dnf and homebrew, I’m not sure. Probably the one that is evaluated last in the path. Maybe someone more versed in Fedora and Linux can elaborated on this. However, I don’t think it is a good idea to install a piece of software with both package managers.
I don’t think it is a good idea to install a piece of software with both package managers.
Yeah. That’s why I asked if there was any overlap between what could be installed with the package managers. Dependency resolution is another factor to take into consideration. Even though a user may not intentionally install the same package with both systems. There is a decent possibility that they could end up with different versions of the same executables being pulled in as dependencies of other packages because one package manager doesn’t know what the other is doing. It can get even more confusing because the PATH variable may not be the same in all contexts (e.g. an application launched via a .desktop icon or from a systemd service may have a different PATH environment setting than one lauched from a terminal). So, for example, if someone runs something that depends on ffmpeg from the terminal, it may work or not work because it is finding the “Homebrew” version of ffmpeg. But if the same application is started from a systemd script, suddenly it behaves differently because it is finding a different ffmpeg binary. That sort of thing can cause quite a bit of confusion and frustration if the end user doesn’t know what is going on.
I’m sure that “advanced” users and developers that understand how these things work would have no problems dealing with such issues. But I’m not sure that it is a good idea to recommend such a system to the general end users who might encounter such problems and might not know how to resolve them.
@glb I understand you. Note that this will be useful mostly for developers that need to install special packages. Also, GUI apps (casks in homebrew terminology) are not installable on Linux AFAIK. Furthermore, some apps are not available as RPM packages, but are available as Homebrew formulae. So, this tool can prove to be really useful in some cases and serve as a complement to dnf rather than to interfere with it.
Personally, it has made my life as a developer easier, for example I can easily install and update Minikube.
There is a disclaimer stated up front in the article (i.e. “Homebrew isn’t officially supported by Fedora Linux.”).
It is emphasized that users should always prefer installing RPM or Flatpak version of a program before trying Homebrew as a last result.
The problems that I mentioned earlier are clearly explained in the article.
A full section devoted to how to completely and reliably undo/remove Homebrew and everything installed by Homebrew from the system in the event of problems is included at the end of the article.
This article has my +1. I’d still like to see at least one other person from the Fedora community (i.e. anyone with a FAS account) give this their +1 before we move forward with the article. (The extra vote doesn’t really mean much. I just want some reassurance that I’m not completely off-base by letting this one go through.)
I’m not convinced it has anything to offer about Fedora Linux other than how to use a non-standard packager to install software on it. I am with @glb about the potential harm to system setup that would result for many not as linux savvy users, is more than just cause for disclaimer, but leans towards irresponsible for Fedora Magazine to publish. As a part of the Fedora community, the Fedora Magazine has a special place in that it has become a reference for material pertaining to using Fedora Linux and it’s packages provided. We must always be aware of the trust that is placed in our role. This article is potentially an editing intensive one.
Is there anything to translate a homebrew package to at least the starting point of a SPEC file for RPM?
I’ve found that offline compiles are the biggest hurdle when translating packages from other systems. (Online compiles are Evil™ and mock turning off network for Fedora is a big win for security)
On the other hand, if you were going to use homebrew, an online compile doesn’t make anything worse.
If that is directed at me, you’re asking the wrong person. I don’t know anything about Homebrew. And I know very little about RPM packaging. Maybe the original poster can answer though.
Some more technical information from the home-brew website and
I started the Install script and got all the path’s and scripts who get installed/created
(622M /home/linuxbrew #after installation):
brew.sh :
It’s all Git and Ruby underneath, so hack away with the knowledge that you can easily revert your modifications and merge upstream updates.
Homebrew installs packages to their own directory and then symlinks their files into /usr/local (on macOS Intel).
Homebrew won’t install files outside its prefix and you can place a Homebrew installation wherever you like.
==> This script will install: #what the install-script proposes
/home/linuxbrew/.linuxbrew/bin/brew
/home/linuxbrew/.linuxbrew/share/doc/homebrew
/home/linuxbrew/.linuxbrew/share/man/man1/brew.1
/home/linuxbrew/.linuxbrew/share/zsh/site-functions/_brew
/home/linuxbrew/.linuxbrew/etc/bash_completion.d/brew
/home/linuxbrew/.linuxbrew/Homebrew
==> The following new directories will be created:
/home/linuxbrew/.linuxbrew/bin
/home/linuxbrew/.linuxbrew/etc
/home/linuxbrew/.linuxbrew/include
/home/linuxbrew/.linuxbrew/lib
/home/linuxbrew/.linuxbrew/sbin
/home/linuxbrew/.linuxbrew/share
/home/linuxbrew/.linuxbrew/var
/home/linuxbrew/.linuxbrew/opt
/home/linuxbrew/.linuxbrew/share/zsh
/home/linuxbrew/.linuxbrew/share/zsh/site-functions
/home/linuxbrew/.linuxbrew/var/homebrew
/home/linuxbrew/.linuxbrew/var/homebrew/linked
/home/linuxbrew/.linuxbrew/Cellar
/home/linuxbrew/.linuxbrew/Caskroom
/home/linuxbrew/.linuxbrew/Frameworks
Press RETURN to continue or any other key to abort:
Because it seems fairly self-contained, it doesn’t look that bad to me. But there seem to be at least a few people who are strongly opposed to it. I’d prefer not to run something if it is that controversial. Thanks for the suggestion Mehdi. But we should probably pass on this one.
I’ve just used brew install reposurgeon --HEAD to install a package straight from upstream repository without waiting for ESR to release a new version with a bugfix I need. That’s pretty awesome. reposurgeon is packaged for Fedora, but the way to wait for the upstream maintainers to release a new version, then for package maintainers to release Fedora package is too long.
TL;DR; I agree with the article even when I wouldn’t use it.
I think there is space for this article in the magazine. IMHO, I think I wouldn’t use homebrew, but if there is a few people that can benefit from using it, there is no harm in putting out the article.
With the proper cautions like the ones mentioned before:
It could be a really good article. Some of the concerns haven’t been addressed before with other “package managers” or ways to install programs (where the binaries are installed, which version will run if both, rpm and alternative, versions are installed), like flatpak, and there are several articles about it.
I think the problem comes from being a macOS designed-app, but we also have articles on PowerShell, .NET and even one on how to install Fedora with WSL2 that it’s still not accepted because of Legal issues.