Open assistcontrol opened 1 month ago
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 wrongI 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)
There is some potential for optimizing away some redundant checks. There will still end up being a dynamic set of uncertainty though.
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!
Prerequisites
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.