

Ask HN: OSX Package Management - unignorant
http://blog.ethanjfast.com/2009/10/osx-package-management/

======
yason
Personally, it seems that we -- as for people appropriately inclined -- have
reached the point where you just want _some_ platform to run Debian/Ubuntu: if
it's OSX, cool; if it's native Ubuntu, okay then, too, as long as it works
well enough with the hardware.

I dumped OSX a couple of years ago and a major part was the package management
trouble.

I need all the basic open-source software as well-laid as in Ubuntu/Debian. I
want them to be compatible, familiar, hopefully in the nice GNU flavor I'm
used to, and preferably as the de facto standard for the system I'm using so
that I won't run into conflicts with the system software itself. For me in
2006/2007, DarwinPorts/MacPorts/Fink/whatever didn't cut it. They weren't as
up to date nor as extensive as Ubuntu/Debian repositories, and I was always
feeling something was lacking in their overall integrity. In Ubuntu, it's the
native software stack and everything just clicks together.

I think it would be really great if you could use a Mac with native OSX to run
your Debian and GNU stuff as well as Ubuntu does.

I doubt Mr. Jobs would agree, though.

~~~
unalone
KDE makes their stuff available for OS X. One day I tried Amarok, partly
because a Linuxing friend used it and recommended it, mainly because the Mike
Oldfield song of the same name is my favorite song of all time. It installed a
bunch of crap on my computer, added a folder directly to my root user, took a
minute to launch, displayed a huge logo while it was launching, presented me
with the ugliest interface I've ever faced on this operating system, took
hours to find my music, then crashed when I tried to play a song.

Apple is of the opinion that its programs have to be unique and special. After
my experience with KDE-on-Mac, I'm going to agree and say that if Linux things
ran instantly on the Mac, the quality of experience for anybody who made an
effort to run them would drop sharply.

I'm fine with the App system on the Mac. It's ultrasimple. Package management
is a teeny bit simpler, but it's not enough for me to bother over.

~~~
antonovka
_I'm fine with the App system on the Mac. It's ultrasimple. Package management
is a teeny bit simpler, but it's not enough for me to bother over._

I'm not sure it's actually simpler; as a software author, my experience has
been:

If I want to release something for the Mac, I post a dmg containing a dragable
application; and even the most non-technical user can download and install it
immediately. Sparkle provides automatic updates via my website; users gets the
latest versions whenever they want them, I don't have to do anything
complicated.

If I want to release something for the UNIXes, I provide a set of autoconf
scripts and a make-based build system (or one of the recent alternatives, or a
Python egg, or a Ruby gem), hope that the package management systems pick it
up during their next release cycle, wind up in an argument with Debian over
OpenSSL+GPL licensing compatibility, and see my software get shipped with half
the featured turned off and a ridiculous number of local hacks applied,
including all-too-regularly replacement of a working library dependency with
something that doesn't work (but Debian likes it more).

The average end-user doesn't see my updates for months or years, the software
is missing features and locally modified, and I have to wonder: Why couldn't I
just give them something that they could drag to their applications folder?

~~~
nuclear_eclipse
You could always provide your own package repository and/or build your own
packages. It's not terribly difficult, and certainly isn't any more difficult
that maintaining your own auto-update mechanism anyways. And if you have your
own package repo, users will get updates from your repository whenever they
update their system...

~~~
blasdel
You still have the problem of having your package's dependencies be
broken/mutilated/ancient -- the only solid way to get around it is to
statically link with your own unfucked builds, but that isn't always possible.

------
nudded
there have been recent developments over an alternative, and
<http://github.com/mxcl/homebrew> seems to be a very nice one.

it's still growing, but seems to be a viable alternative to macports

~~~
tvon
I'm a fan of homebrew, but it is very, very far from being a package
management system. At this point it's basically an installer.

~~~
antonovka
Yes -- if you were around when fink and macports (formerly darwinports) were
nascent projects, homebrew will seem very, very similar.

This is a problem that is very easy to solve 5% of. It's the other 95% that's
a monster.

If we walk down homebrew's feature list:

 _\- Zero configuration installation. Copy the contents of this directory to
/usr/local. Homebrew is now ready for use._

This is how DarwinPorts started out, too. The problem was that eventually the
implementation needed to run some pieces of native code, and a build process
was born.

 _\- Or… install anywhere! You can actually stick this directory anywhere.
Like ~/.local or /opt or /lol if you like. You can even move this directory
somewhere else later. Homebrew never changes any files outside of its prefix._

Fink and MacPorts do the same thing. However, moving UNIX software from the
prefix it was built with will rarely work.

 _\- The GoboLinux approach Packages are installed into their own prefix (eg.
/usr/local/Cellar/wget) and then symlinked into the Homebrew prefix (eg.
/usr/local). This way packages can be managed with existing command line
tools. You can uninstall with rm -rf, list with find, query with du. It also
means you can easily install multiple versions of software or libraries and
switch on demand._

This is what MacPorts does, too. Look at /opt/local/var/macports/software --
every package in their own versioned subdirectory, hardlinked to /opt/local
and managed automatically by MacPorts. You can have multiple versions
installed at once (but only one activated).

 _You don't have to sudo It's up to you. We recommend not--see the relevant
later section._

MacPorts used to not require sudo, but the fact is that users wanted things
like launchd startup scripts installed and daemon users created. You can still
run MacPorts as non-root, but some things (like creating a new user for
postgresql) will break.

In later versions, MacPorts supports acquiring/dropping privileges as
necessary to run non-root when possible.

 _\- Easy package creation. Packages are just Ruby scripts. Generate a
template with ..._

In MacPorts, ports are just Tcl scripts with a very clean DSL.

 _\- DIY package installation MacPorts doesn't support the beta version? Need
an older version? Need custom compile flags? The Homebrew tool-chain is
carefully segregated so you can build stuff by hand but still end up with
package management._

MacPorts supports your own local port files. Copy over the port file (port cat
<portname>) to a new local directory, tweak it a bit, and run 'port install'
from the directory. Done.

 _\- No duplication. MacPorts is an autarky -- you get a duplicate copy of
zlib, OpenSSL, Python, etc. Homebrew isn't, and as a result everything you
install has less dependencies and builds significantly faster._

MacPorts and Fink used to try to leverage the operating system dependencies,
but the fact was that Apple would break those dependencies in minor releases
and in ways that were incompatible with the user-installed software.

More importantly, the dependencies would grow stale and often be missing
requested functionality, leaving users in the lurch and requiring the
introduction of "duplicate" dependencies to the port system.

 _\- Fork with Git The formula are all on git, so just fork to add new
packages, or add extra remotes to get packages from more exotic maintainers._

MacPorts supports portfiles places in arbitrary file://, <http://>, rsync://,
svn://, etc locations. If you want to run your own portfiles, you can do so
through a myriad of equivalent mechanisms (including git).

I'll stop here. The fact is that this problem space is an unexpectedly deep
rabbit hole, and it's very easy to peer down it and think you've solved it,
when in fact you have no idea how deep the rabbit hole actually goes.

MacPorts, Fink, apt-get and friends don't do things in a certain way because
they're stupid, which seems to be so blithely implied in the homebrew
documentation. They do these things because decades of experience have
demonstrated the depth of the rabbit hole and the requirements necessary to
provide a generally useful solution.

There's enormous room for improvement, but it's not going to happen with a
project like homebrew following the exact same footsteps of the projects that
came before -- and making the exact same mistakes.

~~~
hyperbovine
Fortunately the other 95% has been solved several times over: dpkg, RPM,
pacman, etc. Why bother writing another package manager for OSX? I'm puzzled.

Of course, the real problem is that building and maintaining a large package
tree takes a ton of effort, and it's not very interesting work. I think that
this is the real reason why package management is lacking on OS X--no one has
any financial incentive to make it better. With Canonical and Red Hat, they
literally have no product without a healthy package tree. So they pay a lot of
people to package software. There is no corresponding situation in OS X. The
vast majority of their users don't give a hoot, so Apple is not interested.

I think there is a modest but extremely unglamorous business opportunity here.
Get a healthy FOSS package tree going for all arches on OS X and charge people
$1 a month for access. (AFAICT this is allowed by the GPL:
[http://www.gnu.org/licenses/gpl-
faq.html#DoesTheGPLAllowDown...](http://www.gnu.org/licenses/gpl-
faq.html#DoesTheGPLAllowDownloadFee))

~~~
antonovka
_Fortunately the other 95% has been solved several times over: dpkg, RPM,
pacman, etc. Why bother writing another package manager for OSX? I'm puzzled._

MacPorts can actually generate dpkg, rpm, and even Installer.app packages, but
there hasn't been the resources or interest in maintaining a tree of binary
packages. There has also been work into creating a dpkg-alternative via xar.

Fink produces dpkg packages as well, but has resource constraints in producing
up-to-date trees of binaries.

 _I think there is a modest but extremely unglamorous business opportunity
here ..._

Definitely allowed, but could you prevent users from simply copying your
packages to an open repository (ala CentOS vs RedHat)?

~~~
hyperbovine
No, but then again RH made $77 million last year :-)

------
derefr
reason that package management feels so integrated on Linux is that Everything
Is A Package, including the system components. This works because, usually,
every required for a Linux system is open-source and free-as-in-beer.

On OSX, on the other hand, _many_ things that people want to install are
closed-source, for-pay apps. Having different installation and management for
those than for open-source packages is what makes fink/macports et all feel
like ghettos.

A "real" package management system for OSX would be more like a package
_store_ : it would allow you to install both free and paid apps, and handle
upgrading/installing dependencies/uninstalling them equally well. It would
also need to be able to detect and "absorb" responsibility for any apps you
installed from DMGs.

Of course, once such a system was created, Apple would very likely buy it and
integrate it with Software Update.

~~~
hyperbovine
s/Software Update/iTunes

~~~
derefr
I suggested software update because "Apple Software Update" (the Windows
program) is required to be installed on Windows Boot Camp partitions, while
iTunes is not. Apple likes all-encompassing, "we'll take care of everything"
experiences; they wouldn't just go through all the trouble of making it work
on the Mac side and then leave off Windows support (thus making the Apple
Software Store the first thing you'd install on any Windows computer, in order
to pull down all your favorite applications—convenient for them, isn't it?) It
would be much harder to convince people to install iTunes in order to install,
say, Photoshop, than it would be to convince them to install a single-purpose
general-software utility.

------
justinweiss
Until I upgraded to Snow Leopard, I was using fink with the unstable binary
packages: [http://finkers.wordpress.com/2009/06/01/fink-and-binary-
dist...](http://finkers.wordpress.com/2009/06/01/fink-and-binary-
distributions/)

I could use apt and dpkg, it did't build the world whenever I wanted a package
( _cough_ Macports), and since it just used binaries, installs were super-
fast.

Last I checked, fink wasn't all that usable with Snow Leopard, but it's by far
the easiest package management method for Leopard.

~~~
blasdel
Fink is also a ghetto where the maintainers feel free to modify the upstream
packages to their personal preferences.

------
ghshephard
The fact that you can (and frequently do) copy a the .app component out of our
.DMG bundle into your /Applications/ directory means that any attempt at
package management will be half hearted anyways.

------
cschep
Yes, yes, yes.

I'm glad the author mentioned pacman. It's definitely been my best package
management experience. I still use macports, but it does feel pretty tacked
on. That being said I'm definitely excited about homebrew
[<http://github.com/mxcl/homebrew>]. Some initial weekend hacking with it left
me happy that it exists and excited about where it is going. Cheers mxcl!

------
mr_justin
I don't know, I've been pretty happy just building stuff the old school way.
Never been a fan of package managers and especially not macports. I just don't
trust 'em.

