On 10/8/18 2:23 AM, Tom Hale wrote:
I noticed that even when namcap prints out errors, it still exits 0.
I raised this at: https://bugs.archlinux.org/task/60333
It was closed:
Reason for closing: Not a bug Additional comments about closing: namcap runs fine, so exiting with an error makes no sense
To me the "reason for closing" is like saying that diff should exit 0 when two files are different because diff ran fine.
If namcap is to be used in any automated packaging tools (or even my dodgy script), then it makes sense to have meaningful exit codes. And possibly an option to also have warnings also exit non-0 for the persnickety amongst us.
I note that the python source returns 0 and 2, but never 1.
I'm a newbie here, but I believe my argument has merit, so I raise it here for possible discussion.
namcap does unreliable things like repeatedly fail with: PKGBUILD (qbittorrent) E: Missing description in PKGBUILD because it can't tell that the description is in fact in the split package functions. It tells me that split PKGBUILDs need all the split package dependencies as makedepends, even though that's clearly wrong. Its detection of shebang dependencies, unused pthread libraries, "unused" dependencies for python module dependencies, and more, are notoriously flaky. Its recommendation that packages with fonts, desktop files, mime database files, etc. should have random dependencies in order to ensure the respective pacman hooks are triggered... is something I simply consider to be totally wrong. I'd agree namcap can be useful, but I don't give any particular credence to the exit code and I think you should always review every error. If you just want to know what it found, I guess you could list the number of output lines. Also, I have just as many false positives that claim to be errors, as I have false positives that claim to be warnings. tl;dr I didn't close that bug, but I can see the rationale Doug had when he closed it. -- Eli Schwartz Bug Wrangler and Trusted User