On 2019-12-05 Thu 17:00, Alexis Ballier wrote: > > > pkgcheck is mostly used by your CI checks for > > > producing huge reports, which is nice but addresses a different > > > problem > > There is nothing stopping you from running pkgcheck locally. In > > fact, > > it should work out of the box these days. If you have any problems, > > please report them and I'm sure they will be addressed promptly.
> Sure I did that to get reports like what CI does for me now but that's > always been a different usecase; I wasn't aware pkgcheck had the > equivalent of repoman commit While I dislike contributing more to this off-topic tangent, since I've fielded this question/request in IRC a few times in the past I figure I might as well address it again here for the IRC-averse. Personally I use pkgcheck as a QA tool and *git* (or another vcs tool) as a commit tool, just like how I used to use repoman and cvs a long time ago. I generally dislike when cli tools amalgamate disparate features that they weren't designed for so no one has been able to convince me why a tool designed to verify ebuilds and their related repos should support commit capabilities internally. Furthermore, pkgcheck was designed to scale towards scanning multiple pkgs, custom restrictions, or entire repos while I assume the majority of repoman usage is run against singular pkgs. In many cases, a multi-pkg scan doesn't map to a single commit so that functionality would be pretty useless in those situations. To aid those who believe this commit functionality necessary, I've mentioned I would support improving API access and/or configurable exit status settings allowing for easier pkgcheck scripting or other types of external usage. Tim
