Using Homebrew Package Manager on Fedora Linux


Homebrew is a package manager for macOS to install UNIX tools on macOS. But, it can be used on Linux (and Windows WSL) as well. It is written in Ruby and provides software packages that might not be provided by the host system (macOS or Linux), so it offers an auxiliary package manager besides the OS package manager. In addition, it installs packages only to its prefix (either /home/linuxbrew/.linuxbrew or ~/.linuxbrew) as a non-root user, without polluting system paths. This package manager works on Fedora Linux too. In this article, I will try to show you how Homebrew is different from Fedora Linux package manager dnf , why you might want to install and use it on Fedora Linux, and how.


You should always inspect the packages and binaries you are installing on your system. Homebrew packages usually run as a non-sudoer user and to a dedicated prefix so they are quite unlikely to cause harm or misconfigurations. However, do all the installations at your own risk. The author and the Fedora community are not responsible for any damages that might result directly or indirectly from following this article.

How Homebrew Works

Homebrew uses Ruby and Git behind the scenes. It builds software from source using special Ruby scripts called formulae which look like this (Using wget package as an example):

class Wget < Formula
  homepage ""
  url ""
  sha256 "52126be8cf1bddd7536886e74c053ad7d0ed2aa89b4b630f76785bac21695fcd"

  def install
    system "./configure", "--prefix=#{prefix}"
    system "make", "install"

How Homebrew is Different from dnf

Homebrew is a package manager that provides up-to-date versions of many UNIX software tools and packages e.g. ffmpeg, composer, minikube, etc. It proves useful when you want to install some packages that are not available in Fedora Linux rpm repositories for some reason. So, it does not replace dnf.

Install Homebrew

Before starting to install Homebrew, make sure you have glibc and gcc installed. These tools can be installed on Fedora with:

sudo dnf groupinstall "Development Tools"

Then, install Homebrew by running the following command in a terminal:

/bin/bash -c "$(curl -fsSL"

During the installation you will be prompted for your sudo password. Also, you will have the option to choose the installation prefix for Homebrew, but the default prefix is fine. During the install, you will be made the owner of the Homebrew prefix, so that you will not have to enter the sudo password to install packages. The installation will take several minutes. Once finished, run the following commands to add brew to your PATH:

echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"' >> ~/.bash_profile
eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"

Install and Investigate Packages

To install a package using a formula on Homebrew, simply run:

brew install <formula>

Replace <formula> with the name of the formula you want to install. For example, to install Minikube, simply run:

brew install minikube

You can also search for formulae with:

brew search <formula>

To get information about a formula, run:

brew info <formula>

Also, you can see all the installed formulae with the following command:

brew list

Uninstall Packages

To uninstall a package from your Homebrew prefix, run:

brew uninstall <formula>

Upgrade Packages

To upgrade a specific package installed with Homebrew, run:

brew upgrade <formula>

To update Homebrew and all the installed Formulae to the latest versions, run:

brew update

Wrap Up

Homebrew is a simple package manager that can be a helpful tool alongside dnf (The two are not related at all). Try to stick with the native dnf package manager for Fedora to avoid software conflicts. However, if you don’t find a piece of software in the Fedora Linux repositories, then you might be able to find and install it with Homebrew. See the Formulae list for what is available. Also, Homebrew on Fedora Linux does not support graphical applications (called casks in Homebrew terminology) yet. At least, I didn’t have any luck installing any GUI apps.

References and Further Reading

To learn more about Homebrew, check out the following resources:

Using Software


  1. Hank

    I’m running homebrew for the last few months and quite happy, I use it for kubectl, terraform, helm, kubie, chezmoi, etc. stuff that needs to be fresh and I’d need 3rd party RPM repos.

  2. soul-catcher

    That should be perfect for Fedora Silverblue.

  3. Frederik

    snap, flatpak, homebrew. Is this the new UNIX wars? Do any of them actually solve the problem better than rpm or deb? Homebrew is a must on macOS, but it seems to be completely useless on modern operating systems.

    • Carlos

      rpm and deb packages are good for a lot of things, but aren’t ideal for everything. For example, they can be slower to update when packaged by your distribution, and third-party repositories open up security risks since these package types are always given sudo permissions.

      Snaps and Flatpaks allow for apps to have scoped permissions, which is something we’re severely lacking in Linux, as well as a faster source for new application updates. This can be essential for things like browsers when a new 0 day is discovered.

      In regards to Homebrew, having a package manager that’s not dependent on your distribution means you can have all your packages share the same version and availability between different distributions. The same applies to Snap and Flatpak, but I tend to associate those more with graphical apps.

      Overall, we have different package managers to solve different needs and it’s important we change the default behavior of installing all our packages with sudo permissions. It can contribute to critical security issues and system instability.

      • laolux

        Flatpaks have the possibility to issue quick updates if well maintained, but the same goes for rpm and deb packages. The issue with flatpaks are developers who update their flatpak whenever they have a new version, but don’t update it every time that a library used by their app is updated. So the flatpak might stay with an old library with known security vulnerabilities for an extended amount of time. In a regular rpm package this library would likely have been independently updated by the system and the app would either be secure or break because of incompatibilities with the new version of the library. But even if it breaks, you would not be using an insecure app.
        Also, flatpaks make it very easy for developers to deliberately ship outdated libraries, just out of convenience so that they do not need to adapt their app to a changed library interface.
        Having said all that, I do use flatpaks for certain apps, but I tend to trust them less then distro packages. Especially because flatpaks sometimes just serve binary blobs in their build manifests, even for open source apps (see anki on flathub for example). So rebuilding from source can be very difficult.

      • Frederik

        flatpak and snaps that are useful, will have the same level of access to the system as any other useful application, so I really don’t see the security argument. If something is a great idea, that idea should be applied to everything that can benefit from it — surely, granular security is a great idea (which is also why we have users and groups in UNIX, although not quite up to this task). We also had AppArmour and SELinux that tried to address some of the same problems.

        If flatpak or snap provides any security benefits, its only because the operating system is broken. The proper way to deal with that, is to fix the operating system, not bolt on yet another package manager onto an already giant array of package managers. But besides, solving a security issue, is not solving package management. Your points about all these package managers not taking advantage of the operating system is really the key here — they don’t solve the problems of packaging software any better than rpm or deb. At best, its the same. Timeliness is another issue, which is entirely dependent on the resources available. If everybody adopted the same package format and the same conventions on how to package we could just use one format…

      • Ricardo Bánffy

        Homebrew broke my Mac quite a few times. For Macs, I always recommend MacPorts. For Linuxes, I really don’t see the point. If you need bleeding edge versions, there are distro streams for that (although Debian Sid broke my toys a couple times too). Doing things on the back of the OS’s package manager is usually a very bad idea.

        • Hi Ricardo. Thanks for sharing your experience. Could you please tell us how brew broke your Mac system?

      • Stephen

        “rpm and deb packages are good for a lot of things, but aren’t ideal for everything. For example, they can be slower to update when packaged by your distribution, and third-party repositories open up security risks since these package types are always given sudo permissions.”

        With Fedora Linux rpms in the official repo’s are put through the QA test’s that ensure a “not broken system”. Introducing a package manager that is not a part of the system potentially can lead to breakage, as well as introduce security risks.

        “it’s important we change the default behavior of installing all our packages with sudo permissions”

        When are you using sudo to install? Like it’s only necessary seldom, not the default.

      • GroovyMan

        rpm and deb are best examples for a fast and a comprehensive way to keep a system up to date. The bunch of package-managers will bring you a babylonian mess of unrecognized dependency problems no user would accept.
        But if you prefer the Microsoft Windows chaos on your system, you should rely on your 3rd party package managers.

    • Phoenix

      I tend to agree. With the recent package manager presentations, I also wonder what the advantages are and why I want to use them over the existing methods.

      While the author wrote that it does not replace “dnf”, I still question the usefulness for this one on Linux. Even on Mac back in the days I have only touched it once. Fedora, when commonly installed (e.g. Fedora Workstation), already comes with dnf as well as Flatpak. The latter typically dormant, but still available without further installation.

      Considering the examples given in the article, only minikube I did not find using “dnf”. “composer” is part of the built-in repositories with the newest version. “ffmpeg”, when visiting their homepage (, redirects to RPM Fusion for download, a repository which is a must-have when using your computer as multimedia platform, be it games or video/audio editing. It will therefore provide you with “ffmpeg” from the built-in package manager, dnf. ¯_(ツ)_/¯

  4. g

    Instead of homebrew, it’s better to just use nix

  5. Jose J Galvez

    Thank you for an interesting article. The similarities between Homebrew and the AUR (Arch user repository) are striking, both utilize scripts to retrieve compile and install source packages. An issue which was only briefly touched on in the article, however which is very important is the inherent insecurity of the system. This is well known and often debated in the arch community with respect to the aur, but this needs to be emphasized with other package Management systems such as Homebrew. There’s nothing preventing malicious content from entering the aur and I would suspect Homebrew build scripts other than the diligence of users reviewing them. That said the beauty of these systems is that it allows users to install packages which are often missing or not well maintained by the systems major repositories. I would encourage users to carefully review any recipes, build scripts before installing anything from either Homebrew or the aur.

    • Thank you Jose for pointing that out. Yeah, the security of Homebrew as you said mostly relies on the review process of packages that are included in brew formulae, I think most people trust these formula, but bad things can happen all the time and we need to be careful.

  6. Ryan

    Interesting article. I have always seen homebrew as a Mac OS thing and for me I don’t see a use case for having it on Fedora despite having minikube. If I want minikube, I would go to the project page, and install the provided RPM from their releases which will (I assume) install a repo and a gpg signing key (hopefully) so that I never have to go to the page again to ensure I have the latest version. In terms of everything else mentioned (ffmpeg for example) I can get the latest version from other locations or if I really wanted to, compile from source. The only way I would even consider putting homebrew on my system was if I installed it in user space because otherwise I could see some very horrible dependency problems and package conflicts arising as a result of utilising it. Personally I am going to trust a package either direct from the project or through known community sources long before I would trust anything provided by homebrew. For everything else, there’s Flatpak and I get that some people think that the libraries shipping with the applications are a problem, but in terms of a local application that’s really not going to be a massive vector of attack when the entire application is sandboxed (usually) from the installed system, if you’re not happy with the perms on an app, I’ve heard flatseal can help. Anyway as far as it goes I can see that for some people it might be useful, but this one is a no for me.

    • Thank you Ryan for your insights. Before installing Minikube on Fedora, I only used Homebrew on Mac, and I was happy with it. Then, when I decided to install Minikube on Fedora and I went to the project page, they only provided a binary through RPM without a repo, so I would have to update it manually, as suggested to me repeatedly every time I started VS Code, saying there is a newer version of Minikube available. I found the manual update a hassle, so once I realized I could actually install Homebrew on Linux too and I gave it a try, installing Minikube and a few other apps, I really found it easy to use and facilitating. From then on, it takes care of all updates for brew packages by running

      brew update


  7. Fabian

    Can’t we have Homebrew in the official Fedora package repository?

    • Stephen

      No, please don’t even …

      • Fabian

        Why not?

        • Frederik

          Because we already have dnf + rpm, which is superior to homebrew. You’re going to end up with a mess of clashing versions and low quality packages.

          • George White

            There are some widely used libraries (gdal, netcdf4) that have a long list of optional features. Most linux distros don’t install “full-featured” versions, but some use-cases depend on features few (if any) distros enable. In my field, several “mission critical” open-source applications bundle versions of these libraries to work around unsuitable distro packages. If you are porting one of these applications to your platform or writing software that needs to interoperate with these applications, you need libraries with the appropriate features. Build-from-source package managers that allow optional features to be enabled are a big improvement over ad-hoc builds by providing a uniform way to enable and record feature sets.

        • Stephen

          So, where to start? Mostly the reason is that the homebrew packager does not have any concern about or integration with Fedora Linux Workstation, and this can introduce dependency/configuration issues that would lead to problems for the user and their Fedora Linux experience is lessened as a consequence. The gut reaction is for the user to then “Blame Fedora for not allowing unproven packaging methods to succeed” when in fact the culprit is the unproven/non-integrated package tool. DNF will check and manage dependencies for your system, to help ensure there is no breakage, and dnf as shipped by Fedora Linux on Workstation is entirely integrated into how the system is configured. Even using RPM to install a package without DNF is risky since it too will not be as diligent for dependency checking and management of the system, just the package. Fedora Linux is a fast moving ever changing distro, careful consideration is given to ensuring a usable system for the user. When you introduce another packager to the mix, unless it is a direct drop in replacement for DNF, you open the door for unintended consequences.
          Flatpak’s and Snap apps as well as containerized apps are of course a different thing and not subject to the same potential for system library disturbance.
          Finally, I know I am going on a bit here, but every time you install/uninstall something in a non-conventional fashion (using a non approved package manager) your system deviates from the desired state WRT system libraries, due to the dependency chain being ignored for the system, even if it gets the intended software going in the short term.

  8. laolux

    “You should always inspect the packages and binaries you are installing on your system.”
    I think this is a very good warning. However, the installation method downloads a script and directly executes it without saving it somewhere first for inspection. If someone manages to replace that script on github, substantial damage could be caused.
    One might argue that this is not a big deal, because the script is not run as sudo. But keep in mind that when the script is run on your personal device, it can simply upload ~/.firefox with all your session cookies, ~/Pictures with all your (private) pictures, ~/Documents with your personal documents and everything else in $HOME. Given that the script is executed without any check, a potential attacker does not even need to think about obfuscating the intentions in the script.
    To make the attack persistent (for the user), the attacker can simply create a systemd –user unit and have it executed upon every boot/login.
    So please, don’t execute random scripts from the internet without having at least quickly looked at the script before. Github accounts/repositories have been and will be compromised.

  9. Matthew Phillips

    Nothing wrong with choice. Seems like a great tool if you want fresh software, so why not. Some of the arguments against seem a bit contrived, but what’s great is if you don’t like it you don’t have to use it.

    I use Silverblue and try to stick with Flatpaks if they are an option. The ones from the Fedora remote are made from the same source as the RPMs come from. But regardless of the remote, you can get a pretty good sense for when a developer isn’t keeping up because the runtime will fall behind.

    A cool use case for Homebrew might be in a Toolbox container. How about that for security?

    • Seems a good idea to me using it with toolbox.

    • laolux

      A toolbx container can usually access all your personal files in ~/Documents, ~/Pictures, ~/.ssh etc. So using unsafe/untrusted software in a toolbx container protects other users and their personal data, but unfortunately does not protect you very much. It could still steal and encrypt/delete all your private documents. It could likely not steal passwords which you enter or make screenshots, but still cause lots of havoc.

  10. Midge

    I was thinking of adding nix, guix, pkgsrc to the stack, and forgetting the various scripting language package managers (pip & co.), for a true Frankendistro. Well, why not?

  11. George N. White III

    The RHEL universe has “mission critical” applications that are extensively tested when released, but are then used in production for years with a rotating cast of IT staff. Meanwhile, tools that support the application (moving data, changing formats used for images, etc.) need updating. Such tools often require configurations that distro releases don’t provide (think of big libraries like gdal and netcdf with lots of optional configurations), so building from source is often necessary, and is often done using ad-hoc scripts. Using an existing build system is generally more robust and better documented, so should be preferred over ad-hoc “solutions”. The system should make it easy to determine which compilers and options were used for every build by the person who switched jobs last week.

  12. Looks like there is already a discussion around packaging it for distros, though I’m not sure when or if it will happen.

  13. Open To Alternatives

    One advantage of building from source is obtaining architecture specific builds that will give greater performance and a smaller binary size. Something that Arch users benefit from when hardware choices are diversifying – x86, AArch64, riscv etc.

  14. jeremy

    /bin/bash: line 892: cd: /home/linuxbrew/.linuxbrew/Homebrew: Permission denied
    /bin/bash: line 892: return: can only `return’ from a function or sourced script
    /usr/.git: Permission denied

  15. 4wt3w

    how download and using whole fedora offline
    without internet?

  16. Jason

    Interesting article, I use it, but only for simple binaries as a convenience, eg: helm-docs is a simple self contained binary ( yay golang ! ). Using it as an alternative to dnf is likely to end you up in a world of pain

Comments are Closed

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions