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.
1) it puts software into /usr/local, in userland, which is safer from both an OS stability and security perspective, since 99% of installable software doesn't deserve to run as root anyway. And then it modifies the PATH so that the OS first looks there, making it supersede any OS-installed packages.
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
1) So /usr/local is now writable by users? Most software doesn't run as root regardless of where it's installed... I think you mean that you can install into a user prefix without admin privileges, which does make sense for certain packages (if different users require different versions, or something like that).
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?
Point 1 I keep seeing repeated, but it's entirely false. Installing packages as the user does not increase security in the least. If anything, it weakens the traditional unix security model because now the running user owns the binaries, running processes can modify them.
"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.
>If anything, it weakens the traditional unix security model because now the running user owns the binaries, running processes can modify them.
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.
1) Putting everything in /usr/local is far less secure as that means its world writable (oh, my version of bash just overwrote yours, and I added some extra patches ;) ). If it's just in the user's home directory, it's all running as the same user, which is far FAR less secure, now you don't even need privilege escalation to access everything, it's already owned by the same user. Also good luck running anything on standard ports like that. As far as stability, anything that could realistically affect stability can't be installed or run as an unprivileged user anyways. All that being said, with yaourt and makepkg, you can do the same thing, I'm sure there's ways for other systems. Also userland doesn't mean what you think it means.
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)
I can think of several possibilities (not exclusive):
- 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.
Homebrew (mostly?) uses glue code around installing dependencies and doing the ./configure && make && make install dance with sane settings for your environment. It's one-liner, low-hassle installation from source. You're not relying on anyone to be timely/trustworthy about packaging binaries for you.
Honestly I thought the most apparent (to me) advantage to Homebrew over deb/apt/yum is that it's Git based, so incredibly easy to contribute to. I've never contributed an apt package but I have created a number of homebrew packages for different projects it's incredibly easy.
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.
Homebrew was created to add the package manager experience of Linux to Mac OS X, so what gap does this fill?
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.
Both. For example even on my own laptop I would like to keep the admin user's e.g. python and python imaging library as the system python and my general work user's python as the version that works best with the latest numpy-scipy stack and ITK etc.
> 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.
Building from source and installing packages aren't mutually exclusive. Particularly because of the buildroot stuff for GNU autoconf apps, you can just grab '/' in the build root and get everything installed by the build, then update the %files from that (removing common dirs, so your package doesn't own /usr just because it made buildroot/usr).
OTOH if someone said RPM spec format was archaic I'd certainly agree.
Installing to a users home. I.e. no sudo needed for package management. For example I currently install all my python, R and Haskell stuff in my home using each languages' own package management rather than system wide and it would be nice to use the same package manager for all this.
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?
Standardizing a package manager across platforms is nice and making homebrew for linux does this without just creating another package manager to support packages.
Finally! It looks like a lot of commenters here are confused, but there are a lot of situations where the default package Linux package managers don't cut it.
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.
Honest question, in what way is brew faster, more flexible, or more reliable than apt-get or yum? I've had far more problems with it than I have its Linux brethren.
I have never hung my OS X boot simply by updating Homebrew packages.
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.
Sure, but having a separate package manager (or, at least, a distinct package management "realm") for pure userland things that cannot break the OS install so that you know when you install from it you will not break the install, even with dependencies that may get pulled in, is good for piece of mind.
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.
As I mentioned in a different comment, I don't think there's anything about yum/rpm that precludes doing this. Provided someone took the time to create a repository of relocatable rpm's, you could create a "yumbrew" script that does something like
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..)
Dpkg already has a "--root" option to use a different path for both installing packages and storing the dpkg info.
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.
It rather sounds like your preference for brew is that brew is a user-level tool that can't update system packages. There's certainly a case to be made user-scoped package managers are valuable, but "my package manager is capable of updating everything including my kernel" is a feature, not a bug, IMO - brew's constant conflicts with OS X's Apple-provided toolchains should be more than sufficient evidence as to why.
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.
This does make me wonder what is so special or unusual about your various Debian installs. Outside of attempting a woody->sid dist-upgrade in the distant past, I have never had problems with "apt-get [dist-]upgrade" breaking anything to the point of not booting, and certainly not a simple "apt-get update" to refresh the package list. (This is using both Ubuntu and Debian stable.)
>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.
I feel the exact same way, but in the opposite direction.
This is totally silly. Homebrew isn't a very good package manager. When I used it at a previous job (the only time I've used OS X), it was quite unreliable. It would try to build most things from source (which sometimes failed), but then download pre-built binaries for others. IIRC, installing the MySQL package just downloaded a binary from Oracle, it wasn't even a binary pre-built and verified with Homebrew! I have zero confidence in Homebrew to provide any security.
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.
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.
It's one of the key differences between Homebrew and existing OS X package managers (Macports, Fink) and they talk about it quite a lot on the homepage and installation instructions. IMHO one of the reasons it's more popular.
"The standard script installs Homebrew to /usr/local so that you don’t need sudo when you brew install"
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.
The current state of this package looks pretty good! As long as no Homebrew package downloads a pre-built binary from a third-party, I'm content, and I redact that particular criticism.
This package recipe actually builds from source, which is great! I swear that at one point the mysql package downloaded a pre-built binary from a third party site. Even with a cryptographic hash, I don't trust it, because it could have been built with a tainted compiler.
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?
It actually includes methods for both prebuilt binaries ("bottles" in homebrew terminology) and source. It will use a bottle if one exists for your OS version, but you can force installation from source with "--build-from-source".
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/
Best feature of homebrew for me is the possibility to package a software with a pull request.
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.
Am I correct in using the term "bike-shedding" to describe our obsession with package managers, programming languages and web frameworks? It seems every new release changes things just a little bit, usually to make things more comfortable but without much efficiency gains. And we discuss it over and over. Have we run out of hard problems?
Homebrew is not only a weak package manager, it is a dangerous package manager. No one makes it clear anywhere in the docs or on the site that it should never be used on a server or world-facing service...and people are using it for that.
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.
"Does homebrew do any isolation when building from source? Chroots, separate process namespaces, etc."
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.
> 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.
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.
67 comments
[ 3.6 ms ] story [ 131 ms ] threadHowever, I lacked the time to do it and I don't use Linux as my primary OS.
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)
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.
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?
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.
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."
http://brew.sh/
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/
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.
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.