Darwin Version

William H. Magill magill at mac.com
Fri Oct 2 08:21:02 PDT 2015

> On Oct 2, 2015, at 10:33 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
> On Oct 2, 2015, at 8:13 AM, Bachsau wrote:
>> Am 01.10.2015 um 16:08 schrieb Rainer Müller:
>>> It may appear to be still working right now, but there is no guarantee
>>> that it will work at all. Even if it seems to be working now, later
>>> updates will cause problems. For example updates will link to a
>>> different set of new system libraries.
>>> Although cumbersome, the migration procedure ensures that everything
>>> keeps working after upgrading to a new OS X release.
>> What a crap is this? I've been using Arch Linux before and never needed to recompile any third party software, just because system packages where updated. Software that needs to be reinstalled / recompiled on every little operating system upgrade is bad software.
> A few things:
> The migration steps only need to be followed on major OS upgrades, i.e. when the second number in the version number changes, e.g. OS X 10.10 Yosemite upgraded to 10.11 El Capitan. It is not needed for "every little operating system upgrade"; security updates and minor version number upgrades usually cause no problems for MacPorts.
> We're trying to make MacPorts into a system that just works, and that means that when we discover common situations where MacPorts fails to work, we try to modify MacPorts so that users are less likely to encounter them. One of the common problems we discovered was when MacPorts is built on one version of OS X and used on another version of OS X. So now we prevent that, via the error message that caused you to begin this thread.
> The way that MacPorts is built is similar to a lot of other unix software: first, a configuration program is run that determines how things are done on your OS. Then, the program is compiled, using that configuration. Then the program is installed. If you then later upgrade to a different major version of OS, the determinations made at configure time may no longer be true, so the program that was built may no longer work on your new OS. I can think of two cases when this has happened to MacPorts in the past. MacPorts uses OS X's curl library. I think it was in OS X 10.4 that Apple shipped a newer version of the curl library, and no longer shipped the older version that MacPorts used when it was built on OS X 10.3 or earlier. Therefore users upgrading from 10.3 to 10.4 could no longer use MacPorts, because it tried to load a library that no longer existed. Another case occurred in OS X 10.9, when Apple stopped including the /usr/bin/gnutar program in OS X. MacPorts checks for a tar program at configure time, so MacPorts built on 10.8 or earlier would use /usr/bin/gnutar, but after upgrading to 10.9, that no longer exists, so MacPorts would fail to extract anything. The solution to both issues is to re-run the MacPorts configure-build-install process, or run selfupdate which does that for you, or download our pre-compiled installer package for your OS X version. These types of problems are the reason why MacPorts now checks whether the runtime OS X version matches the build-time OS X version, and refers you to the migration page if not.
> The preceding examples concerned MacPorts itself, but since a lot of other unix software (the type of software that we distribute in MacPorts) builds itself in a similar way, this type of problem could easily be encountered in the ports we distribute as well. In addition, new versions of OS X offer new features. Some software may check for those features at build time and enable them if found. By using software built on an older OS X, you might therefore be missing out on some features. These are the kinds of reasons why MacPorts will check whether the runtime version of OS X matches the version of OS X that was in use when the port was installed, and considers the port outdated (i.e. a candidate to be rebuilt) if not.
> When I said we want to make a system that just works, that also includes us wanting to reduce the amount of time we spend on technical support. So you are free to do what you like with MacPorts, and if you don't follow the migration instructions when we say you have to, it may work, but if it doesn't, and you ask us for help, we will not provide support for that configuration.

I’m now retired after 30+ years “playing” in the Unix(tm) vineyards at a major research university - DEC, UNIVAC, ATT, Compaq, HP, IBM, Apple, OSF/1, System V, and too many versions of Linux to name, just to name a few.  Every version of Unix(tm) from every vendor has had and has this release problem.

Some vendors mad “backwards compatibility a priority. Most did not — upgrade the OS, switch vendors, work cross-platform - you were on your own.

> On Oct 2, 2015, at 10:00 AM, Brandon Allbery <allbery.b at gmail.com> wrote:
> Basically, if Apple cared they could make this stuff work. But they don't, so migration becomes a major hassle.

This is the kernel of the issue. It is the implantation of the “Walled Garden” concept. 
It’s Apple’s way or the highway. They know what is best for you.
Pick your favorite snide remark.

MacPorts has done an incredible job of making these transitions possible - and yes I do mean making them possible. 
Without MacPorts, you would have to figure out why XXX suddenly no longer worked and then try to fix it all by yourself.
And that utterly ignores the fact that you would have had to have ported the software to your situation all by yourself.

Thanks for all the hard work!   — Now I have to go deal with the new captain. :)

William H. Magill
# iMac11,3 Core i7 [2.93GHz - 8 GB 1067MHz] OS X 10.10.5
# Macmini6,1 Intel Core i5 [2.5 Ghz - 4GB 1600MHz] OS X 10.10.5

magill at icloud.com
magill at mac.com
whmagill at gmail.com

More information about the macports-users mailing list