Snow Leopard ate my ports

[Ryan Schmidt]

On Oct 13, 2009, at 19:15, Lenore Horner wrote:

>> Whenever you make a major OS or architecture change (PowerPC to  
>> Intel, 32-bit to 64-bit, one OS version to another) you must  
>> uninstall all ports and reinstall them. MacPorts will not detect  
>> these changes, and will assume all ports currently installed were  
>> installed with the current arch and OS version, which is obviously  
>> not correct if you go and change them. So please uninstall and  
>> reinstall all ports now.
>
> Really naive question:  The goal seems to be to have MacPorts use no  
> OS libraries, however we seem to live in an awkward in-between state  
> where MacPorts uses enough OS libraries to break with (at least)  
> major OS upgrades but still requires a lot of stuff to be  
> duplicated.  Is it impossible for MacPorts to be entirely  
> independent or is the restriction people time to fix/write stuff?   
> If it's theoretically impossible, it seems like trying to use as few  
> as possible puts us in a worst of both worlds of having to reinstall  
> MacPorts and having to take the time and disk space to duplicate  
> many OS things.
>
> (Compile time is an issue for me.  So is disk space since I need to  
> keep my disk usage under 40GB so I have enough swap space.)


It is not a goal for a set of ports installed on one Mac / Mac OS X  
version to be usable on another Mac / Mac OS X version. It *is* a goal  
for MacPorts to be able to notice when you have moved from one Mac /  
Mac OS X version to another, and to offer to rebuild your ports for  
you. But that's probably far down the road.

As far as I'm concerned, compile time is not a major source of concern  
for us in general because computers are getting faster and faster, and  
disk usage is not a consideration because disks are getting bigger and  
bigger.

The FAQ explains why we like using our own libraries. It gives  
consistency across OS releases and lets us update things on our  
schedule instead of having it dictated to us by Apple. Take X11 for  
example. It was an exception to the rule before; we used to use  
Apple's X11. But in Tiger Apple's X11 was based on XFree86 and on  
Leopard it was based on X.org. They're different, and we encountered a  
lot of bugs -- first, bugs on Leopard from software that wasn't  
expecting X.org. Later, once Leopard had been out for awhile, bugs on  
Tiger from software that had been updated to work with X.org. Now that  
we have an X.org-based X11 in MacPorts and always use it, no more  
problems. Software builds the same on all OSes.

Ports are allowed to declare "platform" variants to do things on  
different OS versions, e.g. a "platform darwin 9" section to take  
effect only on Darwin 9 (a.k.a. Mac OS X 10.5 Leopard). MacPorts does  
not know whether these differences will result in the files on the  
hard drive being different. Perhaps for some port, the "platform  
darwin 9" section enables a feature only applicable to Leopard. If you  
move this installation over to Snow Leopard, you're now running a  
program with a feature enabled on an OS that feature doesn't work on.

Aside from what can be done in a portfile, the software itself might  
detect things about the OS and build itself differently as a result.  
For example, CoreText was introduced in Leopard. If software is built  
on Tiger, it might detect CoreText is not available and thus not use  
it, whereas if you were to build it on Leopard, it would use it. Or, a  
more modern example, Snow Leopard introduces OpenCL, and something  
similar could happen there. In these examples, you would merely be  
missing useful functionality on the newer OS, but it goes both ways:  
APIs that used to exist get deprecated and removed. It happens all the  
time that ports that used to work on one OS don't work on the next.

Snow Leopard has the additional distinction of being the first Mac OS  
X version to build things 64-bit by default, instead of 32-bit as  
before. This isn't a matter of using or not using some system  
libraries. MacPorts adopts this default as well (because it is error  
prone not to do so) so anything you had installed from Leopard will be  
32-bit but now that you're on Snow Leopard anything you build will be  
64-bit. Try to build 64-bit software against 32-bit dependencies and  
you won't get very far. You must rebuild everything first.