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.
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
