rev-upgrade ignores -p

[fhgwright (Fred Wright)]

If multiple ports require rebuilding due to rev-upgrade (either explicit or implicit), and one of those rebuilds fails, then no rebuilds after that in the list are attempted, even when -p has been specified. This means that broken builds can result in unnecessarily broken ports.

Working around this is made more difficult by the absence of some sort of "port rebuild" command.

[ryandesign (Ryan Carsten Schmidt)]

Rebuilding port X can be accomplished by running sudo port -n upgrade --force X.

[fhgwright (Fred Wright)]

Replying to ryandesign:

Rebuilding port X can be accomplished by running sudo port -n upgrade --force X.

Empirically, that doesn't work. When I try it, it *sometimes* moves X to the front of the rebuild sequence (I suspect that the "sometimes" relates to dependencies), but the only actions reported related to X are "computing dependencies" and "cleaning", with the port remaining in the "broken" state.

While implementing some sort of "port rebuild" that actually works might be nontrivial, I'd expect that making rev-upgrade respect -p would be fairly simple.

[fhgwright (Fred Wright)]

FYI - Not only is this bug still present in 2.5.4, but I also ran across a case where iterating on "sudo port -p rev-upgrade" was able to make additional progress on additional iterations, until finally arriving at the irreducible set of broken ports due to their broken builds.

[ryandesign (Ryan Carsten Schmidt)]

I don't know what to tell you. sudo port -n upgrade --force has always worked to rebuild a port for me. There is no "rebuild sequence"; -n means process that port only, and don't upgrade dependencies. Of course, if a port has dependencies that aren't installed at all, then those will need to be installed first.

I don't have rev-upgrade turned on on my system. Maybe that's relevant. After the rebuild finishes, I guess rev-upgrade would run and might want to do additional things. You could prevent that from happening by running sudo port -n upgrade --force --no-rev-upgrade.

[fhgwright (Fred Wright)]

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.