MacPorts on Linux

[Ryan Schmidt]

tl;dr: I don't know, but isn't it nice that there are now multiple options you can choose from?


On Dec 17, 2011, at 02:44, Niels Dettenbach (Syndicat IT&Internet) wrote:

> But another point here may be - why MacPorts (which is by principe developed and maintained for Mac OS X only) afaik did not cooperate nor participate on well driven / maintained ports projects like pkgsrc?


I don't know pkgsrc; I'm not familiar with operating systems other than OS X, really, so I barely know the names of some of the package managers on other operating systems, and know close to zero about how they work internally, nor do I currently have any interest in acquiring that knowledge; I'm focused on OS X.

A similar question posed 6 months [1] ago asked why MacPorts didn't merge with Gentoo Prefix. As above, I don't know what Gentoo Prefix is either.

I was not involved with the MacPorts project back when Apple started it in the early 2000s under the name DarwinPorts. But OS X had just been created, and was different from Linux and other commonly-used operating systems, and I presume a lot of UNIX software did not work out of the box on OS X, and needed to be "ported" -- patched to work on OS X. Apple's developers were probably the ones best able to construct these patches, given their familiarity with their new OS, but the developers of the software may have been reluctant at the time to accept patches to help an OS they'd never heard of or used, so many of those patches probably had to be maintained in DarwinPorts for some time. Similarly, the developers of other package managers may have been unwilling to accommodate such patches in their systems, as they would unnecessarily complicate their systems for no benefit (and, due to increased complexity and thus increased possibility for bugs, possible detriment) to all of their existing users, who wouldn't have been using OS X. Hence the creation of a new package manager for Mac users. Some further actual history (as opposed to my speculation in this paragraph) is in our wiki [2].

As I mentioned in the last email, it now goes the other way as well: just as other package managers may have been unwilling to accept Mac-specific patches since they don't cater to OS X, MacPorts maintainers might not jump head over heels at the prospect of accepting non-Mac patches, since most MacPorts maintainers have no means of testing such patches, and most MacPorts users have no need of them. We thus have a trend that, even if someone submits a non-Mac patch for MacPorts, it bitrots over time. For example, I am the maintainer of record for ports like zlib and bzip2 that declare in their "platforms" line that they build on other OSes like linux, sunos and freebsd, but I have no idea if that's actually true today since I've never tested it; these claims were there when I adopted the ports years ago and have not been verified since. Some of my ports even call for patches on specific OSes; I have no idea if the patches for non-Mac OSes even apply anymore. MacPorts doesn't even have a straightforward way for me to request that it apply patches that are restricted to other platforms. Any one of the version updates I've committed to these ports over the years could easily have broken the patches and I would never have noticed.

A similar problem already exists even when we focus only on OS X. OS X is still evolving, and Tiger, Leopard, Snow Leopard and Lion each have considerable architectural differences under the hood. For example, Leopard introduced Objective-C 2; today's software written using Objective-C 2 cannot run on Tiger. Snow Leopard defaults to gcc 4.2; software written assuming this version is available might fail to build on Leopard's gcc 4.0. These and countless other differences, and the tendency for developers and users to upgrade to newer OS versions, means that over time fewer people test on older OS versions, meaning problems on those old systems become more common. You can search the issue tracker for keyword "tiger" or "leopard" for some examples. The point is: if we can't even ensure that our ports work right on every OS X system, why should we further fragment our time and attention by attempting to support other operating systems?

Back to the original question, we might also ask: Why was MacPorts created in 2002, if Fink already existed in 2000? I do not know. Perhaps the Apple engineers didn't like something about the architecture or culture of Fink and thought they could make something better. Perhaps there was a touch of NIH syndrome [3]; Apple has been known to suffer from it from time to time. Similarly, we could ask: Why was Homebrew created in 2009? As I understand it, they found MacPorts and Fink too complex and wanted to create something simpler. So now we have three package managers for OS X, each trying to solve the same problem of providing software to Mac users in their own different ways. But is that a bad thing?

More generally, we could ask: Why is there more than one solution to any given problem? Why are there multiple word processors, multiple operating systems, multiple financial institutions, multiple companies that make toasters? The answer is that choice is good. People can try different options and find one they like. You can get a basic two-slice toaster or one that accommodates four slices or one with a bagel button or one that will also cook you an egg or one that looks like Hello Kitty. I started out using Fink, and when it eventually didn't work the way I wanted, I tried MacPorts and liked it better, so I'm grateful I had a choice.


[1] https://trac.macports.org/ticket/29861

[2] https://trac.macports.org/wiki/MacPortsHistory

[3] http://en.wikipedia.org/wiki/Not_invented_here