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