[aur-general] Fwd: FS#60333: namcap exits 0 when errors found (Task closed)

[Eli Schwartz]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20181008/8626ed6d/attachment.asc>