Run new solver with bulk -n

[assistcontrol]

Prerequisites

• Have you checked for an existing issue describing the issue?

The new solver seems great, and I’m spending a fraction of what I used to rebuilding ports.

The new logic is not reflected in bulk -n output.

I’ve always used bulk -n to preview which ports need a rebuild before running it (my poor old server needs comforting when I rebuild node, llvm or rust). The output for ports needing rebuild now always includes the ports that would be ignored.

Can the new logic be run before reporting bulk -n results? I’d expect the output to reflect what actually will occur.

[bdrewery]

The problem is that the shlib checking happens inline - during the build - and depends on dependencies being updated before deciding if a package needs to rebuild. Can't build foo until libfoo is built to decidee if libfoo still provides the shlib that foo wants. If the port for libfoo provided metadata on what shlib and vers were provided then the decision could be made without a build. This problem creates all of the issues I have with the change and why I sat on it for so long.

• -n output is wrong
• 'queued' and 'tobuild' are wrong. Need a 'maybe will build' bucket.
• 'ignored' is wrong (this is fixable by creating yet another bucket like 'inspected')

I don't know how to fix this without more metadata or simply changing what the output of -n and stats are to make clear that there is uncertainty about what will be done.

To be clear, it's not an issue of simply processing packages and checking what libraries they use or provide - we need to actually build some stuff to decide what work is remaining. It's very dynamic now.

The other solution is to not do any of this and rely on PORTREVISION chases. But in my 3 years of testing this specific change (with it being 99% similar during that time), chases are often missed. It's why I put this shlib check stuff in because I kept hitting pkg upgrade errors that made no sense and were hard to debug. The pkg upgrade solver would just go removing packages rather than trying to solve them because shlib versions were not satisfied. I kept thinking the pkg upgrade solver had a bug and spent a lot of time trying to fix it until I noticed the shlibs were actually wrong. (I still think pkg upgrade could handle the situation better but I never could figure it out)

[bdrewery]

There is some potential for optimizing away some redundant checks. There will still end up being a dynamic set of uncertainty though.

[devnull-hub-lab]

Hi @bdrewery

Sorry, just now I saw this issue. I don't usually check here.

Would it be possible to dry-run after calculating the dependencies and the build list, "start" a "build" just to check if the shlib checking step passes? If the step passes, skip the build and go to the next package.
This way, I imagine dryrun could take a little longer, but at least it would correctly show the packages that will need to be builded and those that will be ignored.

As it currently stands, dry-run loses a very important functionality, which is checking the packages that will actually need to be builded. :(

Thanks!

[bdrewery]

No it cannot be done in a separate phase. Each package must be checked after its own dependencies have been built and checked. If foo requires libfoo which requires bar, and both bar and libfoo are not built (and foo does not need a rebuild) we must build bar and libfoo before we can do the shlib check on foo.

It's just not possible to dry-run this stuff. That's the cost of a faster incremental build. The only solution I can see is adding more metadata to ports which is a massive effort. The display problem and lack of dry-run are reasons I sat on this for so long. It is what people want but it complicates things a lot and is unpredictable.