在 Fedora Linux 上使用 Homebrew 包管理器
Homebrew
![](/data/attachment/album/202203/21/193616z7kvf71b7z48kn92.jpg)


### 简介


Homebrew 是一个 macOS 的包管理器，用于在 macOS 上安装 UNIX 工具。但是，它也可以在 Linux（和 Windows WSL）上使用。它是用 Ruby 编写的，并提供主机系统（macOS 或 Linux）可能不提供的软件包，因此它在操作系统包管理器之外提供了一个辅助的包管理器。此外，它只以非 root 用户身份在前缀 `/home/linuxbrew/.linuxbrew` 或 `~/.linuxbrew` 下安装软件包，不会污染系统路径。这个包管理器在 Fedora Linux 上也适用。在这篇文章中，我将尝试告诉你 Homebrew 与 Fedora Linux 包管理器 `dnf` 有什么不同，为什么你可能想在 Fedora Linux 上安装和使用它，以及如何安装。



> 
> 免责声明
> 
> 
> 你应该经常检查你在系统上安装的软件包和二进制文件。Homebrew 包通常以非 sudoer 用户运行，并工作在专门的前缀的路径下，因此它们不太可能造成破坏或错误配置。然而，所有的安装操作都要自己承担风险。作者和 Fedora 社区不对任何可能直接或间接因遵循这篇文章而造成的损失负责。
> 
> 
> 


### Homebrew 如何工作


Homebrew 在底层使用 Ruby 和 Git。它使用特殊的 Ruby 脚本从源代码构建软件，这些脚本被称为 “<ruby> 配方 <rt>  formula </rt></ruby>”，看起来像这样（使用 `wget` 包作为例子）：


（LCTT 译注：Homebrew 本身意思是“家酿”，在这个软件中，有各种类似于酿酒的比喻。）



```
class Wget < Formula
  homepage "https://www.gnu.org/software/wget/"
  url "https://ftp.gnu.org/gnu/wget/wget-1.15.tar.gz"
  sha256 "52126be8cf1bddd7536886e74c053ad7d0ed2aa89b4b630f76785bac21695fcd"

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

```

### Homebrew 与 dnf 有何不同


Homebrew 是一个包管理器，提供了许多 UNIX 软件工具和包的最新版本，例如 FFmpeg、Composer、Minikube 等。当你想安装一些由于某种原因在 Fedora Linux RPM 仓库中没有的软件包时，它就会证明很有用。所以，它并不能取代 `dnf`。


### 安装 Homebrew


在开始安装 Homebrew 之前，确保你已经安装了 glibc 和 gcc。这些工具可以在 Fedora 上通过以下方式安装：



```
sudo dnf groupinstall "Development Tools"

```

然后，通过在终端运行以下命令来安装 Homebrew：



```
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

```

在安装过程中，你会被提示输入你的 `sudo` 密码。另外，你可以选择 Homebrew 的安装前缀，但默认的前缀就可以了。在安装过程中，你将成为 Homebrew 前缀目录的所有者，这样你就不必输入 `sudo` 密码来安装软件包。安装将需要数分钟。完成后，运行以下命令，将 `brew` 添加到你的 `PATH` 中：



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

```

### 安装和检查软件包


要在 Homebrew 上使用“配方”安装一个软件包，只需运行：



```
brew install <formula>

```

将 `<formula>` 替换为你要安装的“配方”的名称。例如，要安装 Minikube，只需运行：



```
brew install minikube

```

你也可以用以下方式搜索“配方”：



```
brew search <formula>

```

要获得一个“配方”的信息，请运行：



```
brew info <formula>

```

另外，你可以用以下命令查看所有已安装的“配方”：



```
brew list

```

### 卸载软件包


要从你的 Homebrew 前缀中卸载一个软件包，请运行：



```
brew uninstall <formula>

```

### 升级软件包


要升级一个用 Homebrew 安装的特定软件包，请运行：



```
brew upgrade <formula>

```

要更新 Homebrew 和所有已安装的“配方”到最新版本，请运行：



```
brew update

```

### 总结


Homebrew 是一个简单的包管理器，可以与 `dnf` 一起成为有用的工具（两者完全没有关系）。尽量坚持使用 Fedora 原生的 `dnf` 包管理器，以避免软件冲突。然而，如果你在 Fedora Linux 软件库中没有找到某个软件，那么你也许可以用 Homebrew 找到并安装它。请看 [“配方”列表](https://formulae.brew.sh/formula/) 以了解有哪些可用的软件。另外，Fedora Linux 上的 Homebrew 还不支持图形化应用（在 Homebrew 术语中称为“<ruby> 酒桶 <rt>  cask </rt></ruby>”）。至少，我在安装 GUI 应用时没有成功过。


### 参考资料和进一步阅读


要了解更多关于 Homebrew 的信息，请查看以下资源：


* Homebrew 主页：<https://brew.sh>
* Homebrew 文档：<https://docs.brew.sh>
* 维基百科 Homebrew 页面：<https://en.wikipedia.org/wiki/Homebrew_(package_manager)>




---


via: <https://fedoramagazine.org/using-homebrew-package-manager-on-fedora-linux/>


作者：[Mehdi Haghgoo](https://fedoramagazine.org/author/powergame/) 选题：[lujun9972](https://github.com/lujun9972) 译者：[geekpi](https://github.com/geekpi) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
## Introduction

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.

#### Warning

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 "https://www.gnu.org/software/wget/" url "https://ftp.gnu.org/gnu/wget/wget-1.15.tar.gz" sha256 "52126be8cf1bddd7536886e74c053ad7d0ed2aa89b4b630f76785bac21695fcd" def install system "./configure", "--prefix=#{prefix}" system "make", "install" end end

## 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 https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

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 ](https://formulae.brew.sh/formula/)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:

- Homebrew Homepage:
[https://brew.sh](https://brew.sh) - Homebrew Docs:
[https://docs.brew.sh](https://docs.brew.sh) - Wikipedia Homebrew Page:
[https://en.wikipedia.org/wiki/Homebrew_(package_manager)](https://en.wikipedia.org/wiki/Homebrew_(package_manager))

## 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.

## Mehdi Haghgoo

That’s good to hear!

## soul-catcher

That should be perfect for Fedora Silverblue.

## Muhammed Yasin Özsaraç

Also for Kinote 🙂

## 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.

## Mehdi Haghgoo

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 (https://ffmpeg.org/), 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. ¯_(ツ)_/¯

## g

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

## Mehdi Haghgoo

I’ve never used nix.

## 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.

## Mehdi Haghgoo

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.

## 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.

## Mehdi Haghgoo

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

.

## 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.

## 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.

## 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?

## Mehdi Haghgoo

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.

## 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?

## 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.

## Mehdi Haghgoo

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

## Mehdi Haghgoo

https://github.com/cantalupo555/repo-solus/issues/49

## 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.

## 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

## 4wt3w

how download and using whole fedora offline

without internet?

## 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