

Ask HN: Homebrew for Linux? - jalan

I recently discovered this project called linuxbrew (https:&#x2F;&#x2F;github.com&#x2F;Homebrew&#x2F;linuxbrew), and it is still under active development.<p>I do use Homebrew for Mac, but on Linux, I am comfortable with the manual installation process.<p>Is this really required for Linux, considering the current scenario? Is it worth the wait and excitement.
======
cobookman
The linux package managers are significantly better than homebrew/macports. If
you're using Debian or a distro based off of Debian (Ubuntu, CrunchBang,
...etc) then you can use apt-get or aptitude.

If you're using redhat or a distro based off of redhat (Centos, ClearOS,
Fedora) then you use the yum package manager.

Finally you have arch linux which uses pacman and yaourt (for non-official
packages).

~~~
dljsjr
I disagree with the first sentence:

    
    
        > The linux package managers are significantly better than homebrew/macports
    

I think homebrew has an infinitely better UI than apt-get (I use both OS X and
Ubuntu full-time at work, OS X and Arch at home). Where the Linux package
managers are better is stability; homebrew doesn't have rigid enough testing
practices to support the aggressiveness in which they update packages. But
that falls on the devs and not the tool.

EDIT:

It seems that people think I meant "GUI" when I said UI. I strictly meant User
Interface; in this case, the command line is the front-end to the user
interface. I feel that homebrew has a better CLI than things like apt-get or
pacman.

~~~
ajdecon
Can you provide some examples of where you think homebrew has a better UI than
apt-get? I can't think of anything in homebrew which feels significantly
easier than apt-get or yum.

~~~
dljsjr
`brew search` + `brew info` is about a million times more sane than `apt-cache
show`, which I find sucks (is usually too aggressive or too specific in its
fuzzy matching) and is poorly named. Plus, why the hell have apt-get and apt-
cache separated in to two commands? Insane.

The output of a `brew install` command is much easier to parse than the output
of a `apt-get install` command. So is the output of a `--dry-run`.

The UI for dependency conflict resolution in `apt-get` is bizarre. And the one
in `aptitude` isn't much better.

I also like that brew is built on git. This is part of the UI for managing
versions (the other being the semi-undocumented and unpublicized `brew switch`
command), and `brew` is a lot more understanding of being able to switch
between versions of packages on the fly.

------
grumps
Why wouldn't you use the package manager that your distro comes with?

~~~
hrkristian
I'm limited by my phone atm, but does this thing have a GUI?

Using Arch I'm in love with Pacman and AUR, and apt and the other package
managers are great/just fine too. They aren't exactly hard to learn so the
only way I see Homebrew being needed is if it provides a great GUI with more
accessible depth compared to existing alternatives.

~~~
grumps
If you're going to run Arch then you should really stick with being
comfortable with the CLI. There's no telling when something will break the
upstream GUI packages, or something wont load on boot and you're stuck in
single user mode.

------
ajdecon
I don't particularly like homebrew compared to the Linux distro package
managers, but I have found it convenient for messing around on my Macbook due
to the large existing library.

A couple of other interesting projects in the Linux software installation
space, which I have been using recently:

* fpm ("Effing Package Management"): [https://github.com/jordansissel/fpm/wiki](https://github.com/jordansissel/fpm/wiki)

Can be used to generate deb or rpm packages given a source directory or
existing package of various types. (For example, generate an RPM from a
Rubygem.)

I use this frequently to quickly create distro packages from software which
only has source available, then put them in a yum repository on S3 for my
private projects. (Creating package repositories is so easy, and signing them
isn't much harder. It's really worth doing.)

* EasyBuild: [https://github.com/hpcugent/easybuild](https://github.com/hpcugent/easybuild)

EasyBuild automates building software from source, and provides a framework
for automating a variety of complex build processes. It's targeted at high-
performance scientific computing, where many of the applications have arcane
or bizarre build processes, and includes modules for a huge variety of
scientific apps.

The big advantage (IMO) is that EasyBuild integrates with Environment Modules
[1], which makes it easy to work with many different versions of the same
software side-by-side. EB doesn't put everything in the same tree; each
package is installed into its own directory and Environment Modules is used to
manage the PATH, LD_LIBRARY_PATH, etc. "module load hdf5/1.8.11" and you're
good.

I use it extensively both on my laptop and on some of the compute clusters I
manage, where users frequently need to be able to switch library and
application versions quickly and easily.

One workflow I've been experimenting with recently: Use EasyBuild to build and
install all packages into locations in /opt on a dev machine, then use fpm to
package them and upload into my repo. Reproduce the system by installing the
relevant packages from yum, and still get the flexibility of using Environment
Modules.

[1] [http://modules.sourceforge.net/](http://modules.sourceforge.net/)

~~~
aktau
Exactly! For anything were I have to deploy, I currently use FPM which you
mentioned together with freight
([https://github.com/rcrowley/freight](https://github.com/rcrowley/freight))
to generate a debian apt repository. Just serve the resulting folder with
nginx/apache/... and you're good to go. It also signs the packages.

------
leoh
The best feature of homebrew, in my opinion, is that it doesn't require sudo
for installation of any package -- in fact, it complains if you try to install
something with sudo. Contrast that, say, with npm -g. Most npm -g installs
will fail without su, unless you are willing to spend a half hour
reconfiguring where dependencies install--pretty fucked in my opinion, as you
could potentially install something really nasty.

Now, many package managers like apt-get use curated databases for their
packages. But in my view, this just is not enough. Homebrew's respect of the
user's system is just superior.

~~~
mekishizufu
> Contrast that, say, with npm -g. Most npm -g installs will fail without su,
> unless you are willing to spend a half hour reconfiguring where dependencies
> install--pretty fucked in my opinion, as you could potentially install
> something really nasty.

It's actually not that bad. You can tell npm where to install "global"
packages in the .npmrc file:

    
    
      prefix = /home/foouser/npmlocal
    

and then just add the bin sub-directory into your $PATH.

> Now, many package managers like apt-get use curated databases for their
> packages. But in my view, this just is not enough. Homebrew's respect of the
> user's system is just superior.

Agreed. This matters even more as a lot of packages are available only through
PPAs.

------
clizzin
Actually, package managers are core to most Linux distributions! That's been
the case long before there was ever Homebrew for OS X. You should almost never
have to manually install from source if you're installing anything relatively
well-known.

If you're using Debian or Ubuntu, you should use the APT package manager. A
good tutorial can be found here:
[https://help.ubuntu.com/community/AptGet/Howto](https://help.ubuntu.com/community/AptGet/Howto)

If you're Fedora or Red Hat, you should use yum, which a tool for the RPM
package manager. Here is a list of basic yum commands:
[http://yum.baseurl.org/wiki/YumCommands](http://yum.baseurl.org/wiki/YumCommands)

You can find more explanations/tutorials if you search using queries like "apt
tutorial ubuntu" or "yum tutorial red hat." Hope you get acquainted quickly!

This might raise the question: Why make Homebrew work on Linux if other
package managers exist already and work really well? I can think of a couple
reasons: 1) fun experimentation, and 2) the fact that Homebrew formulas are
Ruby code, which many people find more approachable to write than APT or RPM
packages. My opinion is that it would be fun to see Homebrew on Linux, but
it's not necessary given that existing package managers work very well, and
many developers are willing to do the work of packaging for the rest of us.

------
aktau
Though I agree that in most cases package managers fulfill this need perfectly
well, there are cases in which homebrew does provide something unique. Which
is the reason that I contributed a tiny bit to linuxbrew (reporting bugs and
suggesting fixes).

1) You need the newest version (ffmpeg for example is something that is often
out of date on linux distros, or what about the latest and greatest gcc or
llvm, or...) 2) Your distro doesn't have it as a package. Case in point,
debian (wheezy) doesn't have ag (the silver searcher). After getting some
issues fixed on linuxbrew, I was able to do "brew install ag" on my debian an
there it was, a fresh silver surfer.

So I don't agree with most posters claiming or implying that homebrew for
linux is useless. The closest (and arguably better) you can get is either
Archlinux or Gentoo (of which I prefer Arch, which I used for a long time),
but if you don't have free choice of distro, linuxbrew gets you quite far.

------
ccanassa
The problem with apt-get for my use case is that most packages are outdated.
If I need to install the latest version of a package I have to Google for
instructions which is quite annoying. e.g. these are the steps to install
Node.js:

sudo apt-get update

sudo apt-get install python-software-properties python g++ make

sudo add-apt-repository ppa:chris-lea/node.js

sudo apt-get update

sudo apt-get install nodejs

[https://github.com/joyent/node/wiki/Installing-Node.js-
via-p...](https://github.com/joyent/node/wiki/Installing-Node.js-via-package-
manager#ubuntu-mint-elementary-os)

------
agj
It's not clear if you are asking about Homebrew or Macports. If you're asking
for a Linux wrapper around Macports, I think you've found it. If you're asking
for a cross-platform build system, NetBSD's pkgsrc
([http://pkgsrc.org](http://pkgsrc.org)) supports Linux -- though there is no
pkgsrc Homebrew equivalent that I know of.

------
laveur
I personally don't see this useful at all for Linux... however I see this
replacing ports on most BSD based systems. Its definitely more modern and
easier to maintain. I use homebrew for my Mac's but for all my linux systems I
use apt/yum depending on the system. I see no reason to use anything else on
them.

------
Gnewt
More power to them, but I'm not sure why they're doing this. Pretty much every
package manager included in current distributions is more useful than
Homebrew. Homebrew only exists to patch a package manager into a system that
isn't built with one.

------
susi22
If you need the most packages and the quickest then you should use ARCH linux.
Otherwise use your package manager (like others have pointed out)

------
rpedela
On Ubuntu or Debian? Use apt-get. On RedHat or CentOS? Use yum.

Homebrew replicates the behaviour of Linux package managers for Mac.

~~~
wglb
I agree, but homebrew replicates only a small part of that the linux package
managers do.

