[MacPorts] #66918: MacOSX10.7.sdk and MacOSX10.9.sdk: Marked as broken by rev-upgrade

[MacPorts]

#66918: MacOSX10.7.sdk and MacOSX10.9.sdk: Marked as broken by rev-upgrade
-------------------------+------------------------
  Reporter:  rmottola    |      Owner:  ryandesign
      Type:  defect      |     Status:  assigned
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:
Resolution:              |   Keywords:  highsierra
      Port:  MacOSX.sdk  |
-------------------------+------------------------

Comment (by RJVB):

 Replying to [comment:1 ryandesign]:
 > Taking as an example the first problem in your log:
 >
 > {{{
 > Could not open
 /System/Library/PrivateFrameworks/ContactsData.framework/Versions/A/ContactsData:
 Error opening or reading file (referenced from
 /opt/local/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/AddressBook.framework/Versions/A/AddressBook)
 > DEBUG: Marking
 /opt/local/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/AddressBook.framework/Versions/A/AddressBook
 as broken
 > }}}
 >
 > Yes, ContactsData.framework does not exist in
 /System/Library/PrivateFrameworks on High Sierra but it did exist there on
 Mavericks and should exist in
 /opt/local/Developer/SDKs/MacOSX10.9.sdk/System/Library/PrivateFrameworks.


 Wasn't there another use case where rev-upgrade balks on a missing shared
 library, ignoring the fact that it's linked weakly and thus doesn't
 (necessarily) throw an error when the dependent binary is loaded?

 Treating the symptom side of things: make rev-upgrade only warn about
 missing dependents that are not installed through MacPorts (or only those
 that belong to the system).

 Another workaround: teach rev-upgrade about the MacOSX.sdk ports. I assume
 that their intention was never to be used as runtime for the binaries that
 you build against them? If so, rev-upgrade should/could scan only for
 missing files but should not do any tests concerning "runnability".

 If however my assumption is incorrect then rev-upgrade does flag an actual
 error and it *may* be possible to fix them with `install_name_tool
 -change` as long as that doesn't change the ids recorded in binaries built
 against these SDKs.

-- 
Ticket URL: <https://trac.macports.org/ticket/66918#comment:5>
MacPorts <https://www.macports.org/>
Ports system for macOS