Homebrew: improved Linux support (and a historical review of our Linux CI)
11-09, 19:25–19:45 (UTC), Room I

Homebrew is a free and open-source package manager, initially written for macOS. Linuxbrew, a fork of Homebrew for Linux, was created in 2012. In 2019, we announced the official support for Linux and Windows 10 (with Windows Subsystem for Linux). The Linux-specific code of the package manager was back-ported from Linuxbrew to the main Brew repository in 2018/2019.

But the story did not end there. The Linux packages were still living in a separate repository: linuxbrew-core. We had to migrate all the changes from the Linux repository to the main repository (homebrew-core). There were more than 5000 lines of code to be back-ported. We also started building Linux packages in homebrew-core, so we had to set up Linux CI along the existing macOS one. As this task is now almost completed and we will soon decommission linuxbrew-core, I would like to come back on the details of this epic migration. This talk will make a small retrospective on why it took us almost 2 years to finish the migration. I will also take the opportunity to discuss the setup of our Linux CI, and the issues we faced while doing so.


The talk will focus on a few topics related to the migration from linuxbrew-core to homebrew-core.

I will go through the way the linuxbrew-core repository co-existed with homebrew-core repository over the years, and why we needed to decommission linuxbrew-core. Keeping linuxbrew-core in sync with homebrew-core has drained a lot of energy out of multiple maintainers, and had become too complex. The current workflow also often broke packages for our Linux users, which was not acceptable. Ending the migration will give us time to finally focus on more interesting tasks and new features, help triage more issues and help our users more effectively.

I will also discuss different CI solutions we have used over the years to build binary packages: Docker hub, Travis, Circle.ci, Azure pipelines and finally GitHub Actions. As we initially did not have any funding for CI, we had to rely on free tiers, which caused a higher workload for maintainers, as a lot of manual intervention was needed. We even built some packages with our personal hardware when necessary.

One last topic I want to discuss is open source maintainer bandwidth, and why it took us two years to finalise the linuxbrew-core to homebrew-core migration. The number of packages to maintain, the number of maintainers, and more importantly the number of maintainers willing to do ops and fix things in the package manager itself will be discussed. Also, I will have a quick look at the financial aspect when it comes to setup CI for a project as big as Homebrew.

I am a Python developer with more than 9 years of experience. I also have 3 years of experience in Java programming.

I am an open-source enthusiast. I am part of Homebrew's technical committee (the missing package manager for Mac (or Linux)): https://github.com/Homebrew/brew. I am also the lead maintainer of the Linuxbrew/homebrew-core project, and of the pygccxml Python library. Check out my GitHub account: https://github.com/iMichka.

I have a PhD in Physics from the University of Lille 1 (France). I speak French, German, English and Luxembourgish. I regularly run marathons (and sometimes even longer distances than that).