Snow Leopard ate my ports

[Lenore Horner]

On Oct 14, 2009, at 04:33 , Ryan Schmidt wrote:

>
> 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.
I asked if it was a goal to have MacPorts entirely independent of OS  
libraries.
>
> 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.
That's fine for you.  However I typically keep a computer for at least  
5 years during which time my speed and and hard drive space don't  
expand.  I also have vague memories of people periodically wondering  
whether installation of this or that had died and the response being  
that it's just something that will take hours to days to compile.    
Another example:  I don't use MacPorts very heavily at the moment so  
my /opt/local is only 1.4GB (and I do use all the recommended cleaning  
stuff up).  However, that's a few 10s of archives of professional  
files or ~photos in tradeoff or about 3% of the space available to me  
on my hard drive for storage (as opposed to swap space).
>
> 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.
I've read the FAQ.
>
> 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.
What the above paragraphs tell me I think is that there is no way for  
MacPorts to be independent of the OS.  Since most of the non-MacPorts  
stuff I use works across several OS's and often on multiple  
architectures as well, I infer that the problem is that it's not  
possible for all possible programs to function this way and since  
MacPorts is one collection of interrelated stuff, even one program  
that won't work so broadly ruins it for everything else.

Out of sheer curiosity, how, roughly, does the decision get made what  
stuff from the OS to use and what not? Is it proprietary Apple stuff  
that gets used and anything available open-source gets done w/in MP or  
is that too simple a division?
>
> 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.
Not being a computer scientist, what's the quick explanation for why a  
machine that can run both 32-bit and 64-bit stuff can't have 64-bit  
stuff talk to 32-bit stuff?

Thanks,
Lenore