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