rev-upgrade: skip weakly-linked

[chrstphrchvz]

Fixes: https://trac.macports.org/ticket/52700

[chrstphrchvz]

I have tested this as a patch to MacPorts base 2.8.1. I have only verified this by checking for expected debug output on a macOS version (12.7) for weakly-linked frameworks which are already present.

I am not certain this is the best approach; maybe it is better for rev-upgrade to only check certain load command types (e.g. LC_LOAD_DYLIB) rather than specifically skip LC_LOAD_WEAK_DYLIB.

[RJVB]

maybe it is better for rev-upgrade to only check certain load command types (e.g. LC_LOAD_DYLIB) rather than specifically skip LC_LOAD_WEAK_DYLIB.

Definitely. The whole (or at least a main) purpose of weak links is that they don't block the launch if a dependency isn't where it's expected to be; rev-upgrade should also disregard them. This is really no different (in practice!) from code that loads a dependency dynamically and thus invisibly to the scanner.

IMHO the most appropriate approach here would be to have a rev-upgrade option that enables checking weak links (but only to dependencies under $prefix?).

(BTW, who ever proposed that name ... revise-upgrade? reverse-upgrade? )

[neverpanic]

Yeah, we should probably only check load commands that we actually recognize and understand. On the other hand, the existing code has worked well since ~2012, so maybe what isn't broken doesn't really need fixing?

I think skipping the weakly linked objects is the right call here, since that's probably the same the the linker would do if there's anything wrong with the weakly linked object, so I'm inclined to merge this as-is. Do you have any idea why the tests failed, is that related to your PR, or can I ignore it?

The name originates from Gentoo's revdep-rebuild. If I had to choose it again, I'd use revdep-upgrade.

[chrstphrchvz]

Do you have any idea why the tests failed, is that related to your PR, or can I ignore it?

I do not know what caused the macOS 11 CI failure, but I do not think it is related to this PR. The same failure has happened before for both macOS 11 and 12:
https://github.com/macports/macports-base/actions/runs/6912577234/job/18808471887
https://github.com/macports/macports-base/actions/runs/6519137742/job/17705304647
https://github.com/macports/macports-base/actions/runs/6371119030/job/17292801824
https://github.com/macports/macports-base/actions/runs/6172017615/job/16751416170

Edit: and again in https://github.com/macports/macports-base/actions/runs/6675230071/job/18142992826

[RJVB]

On the other hand, the existing code has worked well since ~2012, so maybe what isn't broken doesn't really need fixing?

But did weak links exist (in practice) back then?

The name originates from Gentoo's revdep-rebuild. If I had to choose it again, I'd use revdep-upgrade.

Both focus on only part of the functionality, and not the one that interests me (the scanner, which I've also been known use to find unknown/unregistered dependents). And ... upgrade? Isn't the whole point that this allows to rebuild dependents that don't already have an upgrade queued which would normally fix the dependency issues?

[chrstphrchvz]

On the other hand, the existing code has worked well since ~2012, so maybe what isn't broken doesn't really need fixing?

But did weak links exist (in practice) back then?

Weak linking, including with Apple frameworks, has been around since Mac OS X 10.2 Jaguar: https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html

[RJVB]

Weak linking, including with Apple frameworks, has been around since Mac OS X 10.2 Jaguar:

That's why I asked "in practice", but maybe I should have added "in 3rd party software installed through MacPorts" ;) But granted, 2012 is quite some time after OS X 10.2 ... (2003/2004 or so, when I was just starting to become a fanboy again?)