1 |
On Thu, 2019-12-05 at 19:04 +0100, Michał Górny wrote: |
2 |
> On Thu, 2019-12-05 at 18:59 +0100, Alexis Ballier wrote: |
3 |
> > On Thu, 2019-12-05 at 18:39 +0100, Michał Górny wrote: |
4 |
> > > On Thu, 2019-12-05 at 17:36 +0100, Alexis Ballier wrote: |
5 |
> > > > On Thu, 2019-12-05 at 17:09 +0100, Michał Górny wrote: |
6 |
> > > > > +############################################################ |
7 |
> > > > > #### |
8 |
> > > > > #### |
9 |
> > > > > +# |
10 |
> > > > > +# This file specifies packages that are considered |
11 |
> > > > > deprecated |
12 |
> > > > > (but |
13 |
> > > > > not |
14 |
> > > > > +# masked yet). It will trigger pkgcheck warnings whenever |
15 |
> > > > > other |
16 |
> > > > > +# packages depend on them. |
17 |
> > > > > |
18 |
> > > > |
19 |
> > > > repoman would be more useful for this |
20 |
> > > > |
21 |
> > > |
22 |
> > > Then feel free to take repoman over, and start maintaining |
23 |
> > > it. I've |
24 |
> > > lost interest in contributing to the project after the last |
25 |
> > > pointless |
26 |
> > > refactoring made adding anything even more effort, and it doesn't |
27 |
> > > seem |
28 |
> > > that anyone else has. |
29 |
> > > |
30 |
> > > Given that pkgcheck is a. faster by design, b. running checks |
31 |
> > > in parallel, c. has sane API making contributing a pleasure, I |
32 |
> > > don't |
33 |
> > > really see a point in putting any more effort to support a dead |
34 |
> > > repoman. |
35 |
> > > |
36 |
> > |
37 |
> > it's not about who's maintaining what here... |
38 |
> > just s/pkgcheck/QA tools/ and be done with it |
39 |
> |
40 |
> Oh, I've listed pkgcheck there because it's the only tool |
41 |
> implementing |
42 |
> the file at the moment. I'm happy to replace it with larger list or |
43 |
> something more generic once there are other tools. However, I |
44 |
> believe |
45 |
> that saying 'pkgcheck' right now has the advantage that devs know |
46 |
> which |
47 |
> tool to use to see the result. |
48 |
|
49 |
IMHO maintaining such a list is better suited for devmanual or wiki; |
50 |
just like skel.ebuild could be improved by removing portage references |
51 |
and refer to PMS |
52 |
|
53 |
|
54 |
> > pkgcheck is mostly used by your CI checks for |
55 |
> > producing huge reports, which is nice but addresses a different |
56 |
> > problem |
57 |
> |
58 |
> There is nothing stopping you from running pkgcheck locally. In |
59 |
> fact, |
60 |
> it should work out of the box these days. If you have any problems, |
61 |
> please report them and I'm sure they will be addressed promptly. |
62 |
|
63 |
Sure I did that to get reports like what CI does for me now but that's |
64 |
always been a different usecase; I wasn't aware pkgcheck had the |
65 |
equivalent of repoman commit |
66 |
|
67 |
|
68 |
> > i could see this file being useful for auto-generating lists on qa- |
69 |
> > reports like for eapis too |
70 |
> |
71 |
> I don't think there's really a point in duplicating this. |
72 |
|
73 |
For now certainly not. Once someone wants to wipe a deprecated package |
74 |
this could come in handy instead of searching a huge html page, but |
75 |
sure this could be fixed the other way by having this in the per-check |
76 |
reports like what is on the left side of the current CI reports |