Failed/missing packages are not reported
truist opened this issue · comments
After setting up pkg_comp-cron on a new host, I ran a full bulk build. It claimed success, and a visual scan of the output showed that all packages were built.
But when I went to install the packages, 5 of them (out of about 65) weren't built.
So I tried one of them (git-docs) with pkg_comp auto -f devel/git-docs and it ran through the process, claimed that every package built successfully, and claimed overall success. But when I looked closely, the git-docs wasn't even listed as an attempted package.
Digging deeper, I couldn't find any build logs to explain what had happened. (Per issue #3.) I did try manually creating the sandbox (so it would be left behind) and running another build, and I still couldn't find any logs in the sandbox. I was able to find pbulk's reports, and report.txt did show that there were errors, but it didn't show which packages actually had the errors. (This seems like a bug in pbulk, but I'm not sure.) I finally discovered that report.html had more details than report.txt had, and the underlying problem was that python wasn't building because it wanted X11 and I didn't have it installed. So apparently the python package was "masked" and that made dependent builds be automatically skipped.
I don't know if this is fixable via pbulk config; hopefully it is. But even if it is, I think pkg_comp still needs a way to verify if all the requested packages were actually built. It seems like pbulk can't be trusted to report success or failure reliably (at least not when building a specific list of packages), so some sort of post-build check is needed.
I have made earlier attempts at such a script; here is one and here is another that might be helpful.
Heh, thanks for reporting this. I found this exact issue at some point but then vanished from my mind.
At the time, I thought about making pkg_comp verify that all requested packages were built... but this is probably hard to do reliably. There are two problems: the first is that the binary package name does not necessarily match the source name as given to pkg_comp; and the second is how to determine if the package was built on this run or if it's just an old left-over from a previous build.
It seems that the right solution would be to improve pbulk itself to properly report the failure, which I'm surprised it doesn't do already. Or, alternatively, maybe we'd just run make show-var on each package to extract the final package name and search for that value in packages so that we needn't trust pbulk.
I think I found a related issue. If you try to build e.g. www/nginx or www/nginx-devel, you will not find a single mention of either package anywhere in the logs or any other output during the build. If you have other packages to build along with nginx, they will properly built, but nginx seems to get ignored. If you run a build with just nginx to build, then it runs through all scans, enumerates all packages, and that's it. No error, no message whatsoever about nginx.
I've solved my nginx build problem - as described above, it wasn't really ignored, it was just swallowed because the build failed in an quite early stage. In my case it was due to some old make options that weren't supported anymore. After reading the above description, I checked everything, including the make options, and guess what, suddenly nginx was building just fine. I am not sure how we could solve this...but I think it should be given some thought, because I am sure that this will happen more often, especially when packages evolve, change, and we miss some make-option changes in one or another package and therefore don't update our extra.mk.conf.
FYI my wrapper script (that uses my util script) accomplishes this via the make show-var approach. Note, though, that it only checks the desired package list; it doesn't catch missing dependencies. (It should, and could with a little more code.)
But really the util script is sufficient on its own, with just a call to: _do_diff 'desired_package_names' 'current_package_files'.
See Issue #11 for some more details on the wrapper script.