[MacPorts] #56437: rev-upgrade ignores -p

[MacPorts]

#56437: rev-upgrade ignores -p
------------------------+--------------------
  Reporter:  fhgwright  |      Owner:  (none)
      Type:  defect     |     Status:  new
  Priority:  Normal     |  Milestone:
 Component:  base       |    Version:  2.4.3
Resolution:             |   Keywords:
      Port:             |
------------------------+--------------------

Comment (by fhgwright):

 First of all, there is most certainly a "rebuild sequence" with `rev-
 upgrade` - it even tells you that there is when it says "determining
 rebuild order".  This presumably relates to dependencies, since rebuilding
 against a broken dependency may result in a port that's still broken.  The
 issue that this ticket is complaining about is that as soon as any `rev-
 upgrade` rebuild fails, it immediately gives up without trying any others,
 even when `-p` is specified.  Granted, if a dependency rebuild fails, then
 rebuilding any of its dependents may not fix anything even if
 "successful", but it's highly unlikely that that's the reason it stops,
 especially since I've seen cases where it gave up without rebuilding
 something which definitely did *not* depend on the failed-to-rebuild port.

 In some cases, `sudo port -n upgrade --force` of a particular port is able
 to repair its brokenness when rev-upgrade with `-p` gave up without
 trying.  In some cases, it doesn't help, but `sudo port -ns upgrade
 --force` does.  I believe this happens in cases where some dependency is
 unable to rebuild, and thus is stuck at a downlevel version, so a
 precompiled binary linked against the latest version doesn't match, but a
 binary built against the active downlevel dependency is OK.  A smarter
 `rev-upgrade` might need to recognize such cases and force a rebuild from
 source, but that's a different issue than this ticket.

 What's even more bizarre is that there are cases where even a successful
 rebuild from source *still* reports as broken.  E.g., even after being
 masochistic enough to rebuild gcc47 from source, I *still* see it listed
 as broken.  My best guess is that this involves brokenness that's "pulled
 in" from a dependency during a rebuild in a way that's not repaired by
 rebuilding the dependent.  Unfortunately, `rev-upgrade` is woefully
 underinformative, even with `-v`.

 I'm aware of `--no-rev-upgrade`, which is useful in cases where you're
 doing lots of port building and don't want to keep repeating "Scanning
 binaries for linking errors" a zillion times, but that's actually the
 exact opposite of what's wanted here, which is to get a maximally
 effective `rev-upgrade` rather than a disabled `rev-upgrade`.

 Disabling `rev-upgrade` altogether seems like a mistake, since that's
 simply sweeping real problems under the rug.  And the whole C++ library
 thing may create more situations where `rev-upgrade` matters.

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