Linuxbrew – A fork of Homebrew for Linux
brew.sh
brew.sh
Now, I see that people are saying that it fills a niche of having the latest and greatest builds of things. Other GNU/Linux distros already have similar things. Arch Linux's core repo is quite fresh and there's also the AUR for bleeding edge stuff. Debian testing isn't as fresh, but it has most new software fairly quickly. I don't know much about Gentoo, but it's overlay system gives users easy access to custom repos with bleeding edge software. Hell, even Ubuntu seems to have PPA for everything if the software in the release isn't new enough. Then there's some less known options like Nix and GNU Guix that provide very up-to-date packages and have far more features than Homebrew.
In short, we need better system package managers for our distros, not additional package managers to slap on top of the distro we use.
1) To install things in userland
2) To make maintenance easier.
Is there a Linux package manager that puts everything in userland in a place like /usr/local? If not, then it installs things into the operating system, essentially. And that is bad design, pure and simple. You're basically mutating your OS, with nondeterministic results- such as I often run into when I hit "update everything" and my Linux distro then refuses to boot.
That it installs things as a non-admin user is not specific or inherent to its goal.
Yes, yes it is. I was there when it was originally released, and its most radical feature at the time (when root-installing package managers were prevalent) was the change of philosophy of putting things in userland.
And 99% of installable code should live in userland. Without admin privs.
"The standard script installs Homebrew to /usr/local so that you don’t need sudo when you brew install"
https://github.com/Homebrew/homebrew/blob/master/share/doc/h...
"Homebrew installs packages to their own directory and then symlinks their files into /usr/local."
"Homebrew won’t install files outside its prefix, and you can place a Homebrew installation wherever you like."
GNU Guix and Nix.
I am a core developer for GNU Guix.
No halfway-knowledgeable linux user cares about this because...
If not, then it installs things into the operating system, essentially.
...this is only true for a Mac, where a third party comes in and opaquely modifies your entire filesystem with no accountability. On a linux distro the OS is upgraded through the package manager, so a userland install is not a needed feature.
And Homebrew has a terrible track record with #2 as well. Certainly it's not going to beat any of the forementioned package managers.
https://github.com/Homebrew/homebrew/blob/master/Library/For...
Most (all?) "formulas" include cryptographic hash checks for any downloaded files: https://github.com/Homebrew/homebrew/blob/master/Library/For...
This brings me to an issue that I have not only with homebrew, but with most other package managers: reproducibility. Can I have any confidence that the binaries built on your machine and my machine are the same?
The problem of bitwise-identical / deterministic builds is difficult when using most legacy tooling, in particular tools that insert timestamps or other non-determinism. Bitcoin and Tor use Gitian https://gitian.org/ and Google just open sourced their tool, Bazel http://bazel.io/
Mac users already experience issues relating to having multiple non-default package managers (i.e. Homebrew and MacPorts) - what conflicts will having a default and non-default package manager arise?
The problem it is trying to solve would be better approached hosting Debian, RHEL etc repositories which mirror each other in their structure.
I disagree, and I think Linuxbrew fills a different niche.
When you install something from your distro's package manager, you are actually installing another program that happens to come with the operating system. This has two implications:
- It's usually fixed at a particular version for that distro release.
- It's installed into the root filesystem or /usr.
When you compile something from source or download a pre-compiled .tar.gz, on the other hand, it's not something that came with the operating system, it's a third-party package installed by the administrator, and the rules are a bit different:
- You usually grab the latest version or a very specific version from the vendor's website.
- The correct place to put it is usually in /usr/local.
This is where the FreeBSD ports tree puts programs, and this is also where Homebrew puts programs in the OSX version at least. Assuming that Linuxbrew does the same thing, I believe Linuxbrew aims to be the ports tree equivalent for Linux.
OTOH if someone said RPM spec format was archaic I'd certainly agree.
Up to date versions of packages.
Some packages conflict in the repos e.g. ffmpeg and libav on Debian derivatives and keeping both is annoying.
I would rather something like Nix or Guix over this (and as you say standardisation between package managers would be massive).
In short linux package management is great but it could be so much better and this might be a kick in the right direction?
Because it is installed in userland (its most advertised feature), it runs everything as the same user (probably an admin level user with sudo privileges). This throws away 40 years of basic UNIX security wisdom. All so you can install it without sudo.
I recently set out to make our software (and all of its dependencies) installable on Mac OS X. I tried Homebrew first, because it seems so popular and well-liked. But, it's just awful. Coming from a couple of decades using Linux package managers, it's like stepping into the stone age, and it's absurd to bring something that is vastly inferior to the existing options on Linux over. I even blogged about it, for a variety of reasons (mostly to warn people off of the thing): http://inthebox.webmin.com/homebrew-package-installation-for...
Frankly, this is like porting the DOS command line to Linux (which has probably happened at some point, but hopefully as a joke or to solve a specific problem).
So, if you're going to use this, know that it is for home use. If you are putting this on a server for installing services (as I found many people on the web doing with the Mac version) you are doing it so wrong.
To go along with this theme, I must ask: Does homebrew do any isolation when building from source? Chroots, separate process namespaces, etc.
>All so you can install it without sudo.
This is actually a really great feature. I work on a package manager called Guix, which also allows for unprivileged package management. It's one of my favorite features. You and I could have user accounts on the same machine and use different versions of the same application without conflict.
Of course, I don't know what the security story is for Homebrew, but it doesn't look to be better than average. We take security very seriously with Guix, to the point that we are seeking things like bit-for-bit reproducible builds.
No. This is why they install as the user. "For security", you see.
I agree that non-root installs are a useful feature for some scenarios. But, the problem with that for servers is you need to be able to start all of your services as different users. That's really not optional. How you get there doesn't really matter, to me, but dpkg and RPM have long had it solved.
I've looked at Guix and Nix, and find them neat. I'm kind of a package management nerd (and I judge all operating systems by their package management story...Windows and Mac OS X are unacceptable, most modern Linuxes are pretty pretty good, FreeBSD is getting better). I'm not sure I'm willing to make all of the tradeoffs and move onto such a foreign system layout, but it's on my radar.
Anything with an attack surface also must not be able to replace its own binaries/code. Otherwise a one-time exploit is instantly updated to a permanent infection.
Homebrew is the missing package manager for OS X. Linux has package managers, so why a fork? Packages just available through homebrew?
Features
Can install software to a home directory and so does not require sudo
Install software not packaged by the native distribution
Install up-to-date versions of software when the native distribution is old
Use the same package manager to manage both your Mac and Linux machines
- Mac users switching to or using linux, so no familiarity with other package managers to lead them elsewhere.
- Packages are easy to create with their ruby DSL; it might appear gimmicky but it's very easy to pick up despite possibly being less robust? The command `brew create <tar file url>` even creates a template for you.
- CLI is super easy to use; `brew info <package>` tells you everything you need to know; not a significant advantage for anyone willing to read a man page.
- Existing packages as you said, plus it's still a hip package manager so... following contributions is easy? (Again, not a significant advantage except maybe for beginners.)
Most likely: the people who are already familiar with it want to use it elsewhere (their VMs, dual-boot setup, servers, ...).
Edit: Plus whatever is "unique" to brew / what totalrobe listed.
That said, I don't think yet another package manager is necessarily the right solution unless linuxbrew can find dependencies installed by apt/yum so it's not a "one or the other" scenario.
Conflicting with the system's package manager is obviously the most problematic issue with porting homebrew to linux, and I can imagine there's many more caveats that would render such a thing pretty useless.
2) it uses git
3) it has a really nice Ruby DSL (probably lost on you)
4) as I've mentioned elsewhere here, I've OFTEN hung my Linux distros on the next boot by doing a simple "apt-get update". This has NEVER happened in years of using Homebrew.
5) If you Linux folks had any sense of design (software or otherwise) to begin with, your OS wouldn't be primarily relegated to the backend, so the fact that you're one of dozens of people repeating the same "we don't need another package manager" doesn't surprise me in the least, because you guys wouldn't recognize a better design if it pulled up to you in a bus like this: https://www.youtube.com/watch?v=sLB-uMPj27s
You can probably accomplish something similar with yum/rpm though by using the downloadonly plugin and using relocatable rpm's (though probably most distro rpm's are not relocatable, but that doesn't stop someone from creating a custom repository of relocatable rpm's and offering a script that does something like yum-downloader --resolve --destdir=~/.myrpms ; rpm --prefix=~/.local/ --dbpath=~/.myrpmdb -Uvh ~/.myrpms/* )
2) So? A repository of rpm specs or the debian equivalent could also be stored in git...
3) Maybe that's nicer, but it could probably build a .spec file (or the debian equivalent) as well in the same DSL which would be superior.
4) Probably because you never installed a kernel or other system package using homebrew
5) Yes homebrew, a third-party hacky collection of scripts necessary because OS X does not provide basic tools for managing software, is an example of superior OS design by Apple?
"run as root" is nothing to do with this. Who installs the package and who runs it are entirely disconnected. If I install a package as root, and run it with my user, it's running as my user, not root.
All it actually illustrates is that the package manager is not trusted. You don't give homebrew root so that it can't damage the OS by accident. The end result is a binaries that are at risk from errant processes, but it seems this is preferable to trusting homebrew.
This is a great issue to point out. This is why package managers like Nix and Guix (and maybe others I do not know about) use an immutable store for package builds. Unprivileged users may still install and use the software in the store, but the Unix security model prevents them or a malicious process running under their user account from corrupting what has been built.
2 ) You have yet to show why that's a good thing, but https://aur.archlinux.org/packages/?O=0&K=git so what?
3) makepkg has a really nice Bash DSL (probably lost on you) (and also a load of really nice docs)
4) You have indeed mentioned that everywhere, but don't seem to realize that generally software that can hang your "Linux distros on the next boot by doing a simple "apt-get update"" can't be installed or (directly) run as a non-privileged user. Have fun with your grub install in /home, let me know how that hangs on the next boot. Also I wasn't aware that updating a package list modified anything but the package list, but hey, if you say so.
5) If you Arrogant folks (can't even say mac folks, most are reasonable) had any sense of functionality (software or otherwise) to begin with, your OS wouldn't be primarily relegated to a status symbol, so the fact that you're one of the dozens of people repeating the same "we don't need to learn more than one shiny button" doesn't surprise me in the least, because you guys wouldn't recognize better functionality if it pulled up to you in a bus like this: https://www.youtube.com/watch?v=tmYrWXhFf4c
Sorry, got a little angry there, I dont hate mac folk, just arrogant folk from any camp and I recognize the appeal of and need for good design (which brew is not)
After getting used to the (update) speed, flexibility, and reliability of Homebrew, it's shocking and frustrating to go back to Linux, where package managers were born, and have to settle for a less robust ecosystem.
Homebrew is fucking atrocious compared to a package management system like dpkg/apt.
I have frequently hung up my Linux distro boot simply by apt-get updating. To the point that I now run all my Linux OS'es in a VM and take a snapshot prior to updating. Coming from a Mac background, this possibility is not only ridiculous, it's fucking unacceptable. And it happens BECAUSE apt-get and yum mutate the OS install instead of installing into userland the way Homebrew does.
Game, set, match.
It might be better to have a single package manager which supported bother user and OS packages, and clearly distinguished between them, but in the absence of that it is good to have a way to install what you intend to be user packages with an assurance that they won't be installing OS-level things that might break the OS install.
Even aside from this guarantee, its good to be able to install things for a user, but to have other users on the same machine whose environments are unaffected by the install.
yum-downloader --deps --destdir=~/.myrpms foo-1.3.3.7; rpm -U --prefix=~/.yumbrew/ --dbpath=~/.yumbrewdb ~/.myrpms/*
or whatever version of that would actually work. This has the added advantage that you don't have to compile the packages (although if you wanted to, you could make the script do that too..)
I think the biggest issue would be having it recognise packages already installed in the system when it's using a different info directory - it's possible a lot of packages would get re-installed "locally".
Other than that, I believe your concept should work on Debian.
apt-get et al are extremely capable package managers, and in my experience result in much more stable and consistent installs than brew does, specifically because it can be aware of things like OS-level dependencies which it can then manage.
I feel the exact same way, but in the opposite direction.
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/linuxbrew/go/install)"
On the other hand, Homebrew packaging _maintenance_ is done by homebrew maintainers.
Sooner or later, when they achieve the thousands-of-packages mark, they'll need packaging guidelines, and then packaging rules, and then a packaging team (maybe with their own email domain [@debian ;)].
When (if) this happen to linuxbrew, you'll have another linux distribution.
However, I lacked the time to do it and I don't use Linux as my primary OS.