Why does macports require a migration across major version bumps?

[Joshua Root]

On 2017-9-2 16:29 , Eitan Adler wrote:
> 
> 
> On Friday, 1 September 2017, Joshua Root <jmr at macports.org 
> <mailto:jmr at macports.org>> wrote:
> 
>     On 2017-8-30 11:01 , Eitan Adler wrote:
> 
>         What is the underlying reason to require a reinstall across major
>         versions? I did something silly/stupid/smart  and removed the check
>         from libexec/macports/lib/macports1.0/macports.tcl and just did
>         'sudo
>         port upgrade outdated' to rebuild the world. It got about 90% of the
>         way through and only errored on a few expected
>         broken-for-other-reasons ports.
> 
>         Obvious I'm down the deep hole of unsupported actions but I'm
>         curious
>         about what gets missed when someone does this?
> 
> 
>     It's the same reason there are separate installers per OS version in
>     the first place: Many features are detected at configure time. If
>     the same features are not available at runtime, stuff breaks.
> 
>     It's possible that nothing relevant changes between certain major OS
>     versions. It definitely does between others.
> 
>     If we were able to detect all features at runtime, we could have a
>     single (base) build that would work on all supported OS versions.
>     All the many ports that detect features at configure time would
>     still need to be reinstalled of course.
> 
> 
> Note that I am doing a complete reinstall by using port upgrade 
> outdated. Is this not sufficient?

*If* you have installed a version of macports base configured for your 
current OS (which is what you were initially not doing), and *if* you 
use trace mode (the -t flag), this should be sufficient.

Simply upgrading the ports without trace mode can fail due to things 
like opportunistic use of tools by configure scripts (e.g. grep, gsed, 
gawk). These aren't actually needed because the system versions work 
fine, but autotools prefers the GNU versions when it finds them. So 
there's no dependency declared, so we can't ensure that things are 
upgraded in the right order, so executables may fail to run due to 
missing or incompatible libraries at certain points, or more subtle 
incorrect behaviour may result from using something that was configured 
for the old OS version.

There are many examples of such failures, which were resolved by 
following the Migration instructions, in Trac and the mailing lists over 
the years.

- Josh