Created attachment 181086 [details] Amend error message with list of unsatisfied dependency patterns Normally you'd get an error message like: This means a dependency is wrong since it was not satisfied in the TEST_DEPENDS phase. and have to scroll up and dig around to understand *which* dependency wasn't satisfied correctly. This patch collects the list of unsatisfied dependency patterns and shows it in the error message.
Could you provide an output of without/with the patch to see what it does ?
Well, it simply adds an output line saying which patterns were unsatisfied. I guess that in 99% of port developers' cases, this simply never happens. In my example, I had a custom setup (poudriere with own changes) which led to these dependency errors: Without patch: > =======================<phase: test >============================ > ===> Staging for hhdate-2.1.0 > ===> Generating temporary packing list > install -m 0644 /wrkdirs/usr/ports/devel/hhdate/work/date-d110f07f596d86e63daa2db41f1d52c05f4a179c/date.h /wrkdirs/usr/ports/devel/hhdate/work/stage/usr/local/include/ > ====> Compressing man pages (compress-man) > ===> Testing for hhdate-2.1.0 > ===> hhdate-2.1.0 depends on file: /usr/local/bin/clang39 - not found > ===> Installing existing package /packages/All/llvm39-3.9.1_2.txz > [porttesting-devel] Installing llvm39-3.9.1_2... > [porttesting-devel] `-- Installing libxml2-2.9.4... > [porttesting-devel] `-- Extracting libxml2-2.9.4: .......... done > [porttesting-devel] Extracting llvm39-3.9.1_2: .......... done > ===> hhdate-2.1.0 depends on file: /usr/local/bin/clang39 - found > ===> Returning to build of hhdate-2.1.0 > ===> dp_STRICT_DEPENDS set - Not installing missing dependencies. > This means a dependency is wrong since it was not satisfied in the TEST_DEPENDS phase. > *** Error code 1 With patch: > =======================<phase: test >============================ > ===> Staging for hhdate-2.1.0 > ===> Generating temporary packing list > install -m 0644 /wrkdirs/usr/ports/devel/hhdate/work/date-d110f07f596d86e63daa2db41f1d52c05f4a179c/date.h /wrkdirs/usr/ports/devel/hhdate/work/stage/usr/local/include/hhdate/ > ====> Compressing man pages (compress-man) > ===> Testing for hhdate-2.1.0 > ===> hhdate-2.1.0 depends on file: /usr/local/bin/clang39 - not found > ===> Installing existing package /packages/All/llvm39-3.9.1_2.txz > [porttesting-devel] Installing llvm39-3.9.1_2... > [porttesting-devel] `-- Installing libxml2-2.9.4... > [porttesting-devel] `-- Extracting libxml2-2.9.4: .......... done > [porttesting-devel] Extracting llvm39-3.9.1_2: .......... done > ===> hhdate-2.1.0 depends on file: /usr/local/bin/clang39 - found > ===> Returning to build of hhdate-2.1.0 > ===> dp_STRICT_DEPENDS set - Not installing missing dependencies. > This means a dependency is wrong since it was not satisfied in the TEST_DEPENDS phase. > List of not found patterns: /usr/local/bin/clang39 > *** Error code 1 I believe the output is helpful because if something catastrophic like that happens, you want verbose output of what exactly wasn't satisfied (there could be many patterns defined).
I was agreeing to everything, and was able to commit the patch, and then, I began to wonder. It does not make any sense, the clang39 dependency was installed, so, why do you need to have the pattern shown ?
I didn't have this error very often, and the last time I saw it I wanted to dig to see where it came from. This time, it was from our custom poudriere patch which (I believe) failed to set option TEST correctly but still ran the target "test" nevertheless, which led to inconsistencies of the installed dependencies. Long story short: whatever the 0.001% case would be in which you get that rare error, you may want to see verbose output of what exactly wasn't satisfied. I'm not pressing to get this into the tree. If you think it's useless, then let's just ignore it ;)
I don't think it is useless, I just don't understand what you think it should be doing. Right now, what it does is tell you the patterns of the dependencies that have been installed, with a confusing message wrongfully saying that they have not be installed. What I am trying to understand is a real use case.
(In reply to Mathieu Arnold from comment #5) > Right now, what it does is tell you the patterns of the dependencies that have been installed, with a confusing message wrongfully saying that they have not be installed. I did not change the logic in the script, I believe. Just like before, I'm setting anynotfound=1 but additionally collecting the pattern of what was *not* found (file/path/package pattern).
No, I get what you do, you are collecting patterns for dependencies that were not there before, and that have been installed. I just don't understand what it is good for, as the dependencies are installed. And if a dependency cannot be found, it will stop right there.
Most probably I simply have a misunderstanding of what the "strict depends" check is actually used for. I'm closing this for now and if I ever find a real use case (that is fully reproducible), will check again if additional logging can be helpful. Thanks for helping me clarify.
Well, STRICT_DEPENDS *was* created on 2015-04-21 to catch cases where a dependency would be foo:category/bar but the bar port would not install "foo". It has been made obsolete on 2015-06-28 when the depends targets were rewritten.
That even more reduces potential use cases, so mine seemed to be an absolute exception. No need to put effort into this.