Hacker News Reader

Comment by blasdel | Hacker News Reader

Someone's finally gone and written the package manager I've always wanted -- one that can just run in your home directory unprivileged and reuse most of the system packages. Also source-based and plays along with upstream by default!

I'd really love to see someone make this portable to other unixes -- it'd be lovely to finally have good package management for the ~/mine/bin dirs I have on servers everywhere (though a major complication is Debian's obnoxious segregation of headers into separate packages)

View on HN

"a major complication is Debian's obnoxious segregation of headers into separate packages"

What's so obnoxious about this? The -dev packages will depend on libfooSONAME (and have far more stable names) so it's hardly more effort to keep them installed.

I don't know of any way to have apt always pull them in as dependencies, so I constantly find myself installing them manually.

Debian's policy of splitting all features off into their own packages (or disabling them entirely for ideological reasons), and having duplicates of many packages (with mutually-exclusive dependents) constantly fucks with me. I can't ever depend on its dependency tracking to actually give me what I want. It's not a good sign when all the digg-bait walkthroughs always instruct you to paste in a huge list of packages.

Aw, your argument was good until you referred to digg-bait walkthroughs. :] Ideological and/or legal disabling aside, these seem to be implicit drawbacks of using a binary distribution. If you link some app against libfoo, you will almost certainly need libfoo at runtime.

Hm, no apt configuration needed, just install the -dev packages and you'll get the relevant .so too. This seems to be the correct case to optimise for, not the other way around.

Except that other packages always depend on foo, and never foo-dev as a matter of policy, even where it makes no goddamn sense (setuptools doesn't depend on python-dev, rubygems doesn't depend on ruby-dev, etc.).

I'd still have to either constantly be installing foo-dev packages despite already having foo, or succumb to the digg-bait technique of never letting apt think for itself.

Please give up on digg bait. It's an unhelpful useless addition that only serves to insult people. What does insulting primary digg users get you? It's now gotten you two negative replies, and derailed the conversation from its original purpose.

Sure, I didn't have to reply, but I'd like to keep this community interesting and most importantly, constructive.

Is there a better term for the standard adsense-fueled "Hack your Ubuntu iPod with Compiz Fusion!" articles that always contain big <pre> blocks of "sudo apt-get install ..." for the reader to mindlessly copy and paste?

I'd really love to see someone make this portable to other unixes -- it'd be lovely to finally have good package management for the ~/mine/bin dirs I have on servers everywhere

Amen. That could be hugely powerful.

For home directory stuff, I've found that just git can be quite sufficient for tracking and syncing dotfiles and ~/bin.

Naively syncing ~/bin only works when all your systems run the same kernel, on the same architecture, using intercompatible versions of system libraries and programming language runtimes. It also doesn't solve the package management problem at all!

With homebrew, you could sync just the dotfiles and the list of installed packages, and let it take care of installing/upgrading packages on each machine. It'd be even better if it was smart enough to not shadow system packages when they are present+adequate.

> That only works when all your systems run the same kernel, on the same architecture, using intercompatible versions of system libraries

If dotfiles aren't compatible across OS kernels, you're doing something wrong. I keep scripts in ~/bin under VC, but with anything that needs to be compiled I just track the source and build with make (or emacs, etc.). You don't need to put everything in ~/bin in the repository!

From the summary, I don't really see how the system would work transparently across OS X, Linux, and BSD. It looks like it expects git + Ruby + OS X, and I don't use the latter two. (I prefer Lua and OpenBSD, respectively, but that's me.) Also, I work with i386, amd64, and occasionally sparc, and the platform thing isn't an issue since I'm not syncing binaries.

Yes, right now homebrew is specific to Mac OS 10.5+ -- the second paragraph of my original comment is pining for portability, so it could be used on shell accounts and beyond.

A major use case is the ability for your app to be able to pull in it's own sandboxed dependencies in a crossplatform way -- so anyone can develop on their macbook independently of their system is set up, and deploy on any worthwhile server regardless of its setup.

gem does a pretty damn good job of this for Ruby libraries, but it doesn't help at all for the native libraries and utilities that the gems are wrappers around :)

Well, there's the Unix distro package system and another repository for Ruby gems and CPAN and LuaRocks and Hackage and ... They keep stepping on each others' toes, but I'm not sure the solution is to add even more mutually incompatible packaging systems. By their nature, they need to see the system (inc. what dependencies are available) as a whole to be really useful, and fragmenting that picture makes the situation worse for all involved. (On second reading, it looks like it's designed to try to work with CPAN et al, so that's an improvement.)

It would be nice if it actually worked, but coming up with a perfectly portable global packaging system would be hard enough if it was working across platforms for one vendor, let alone the big mob that is the open source world.

Hi I wrote Homebrew, and this is one of my goals, I've always wanted installing from source on Linux to get package management too. I do a lot of cross platform dev, and would also love for this to work on Windows. But that may be too lofty a goal.

I also added the feature where you can specify a git:// or svn:// protocol for a formula so you can easily keep up with HEAD development for your favourite project.

Reply on news.ycombinator.com