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.
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.
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?
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...
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.
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.
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...)
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)?
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.
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.
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.
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.
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!
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.
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.