1 |
On Wednesday 23 May 2012 15:52:11 Zac Medico wrote: |
2 |
> On 05/23/2012 12:21 PM, Mike Frysinger wrote: |
3 |
> > Rather than copying & pasting the same behavior for the different eclass |
4 |
> > checks, add a common class for them to extend. This makes adding more |
5 |
> > eclass checks trivial, and keeps down bitrot. |
6 |
> > |
7 |
> > This does abuse the checking interface slightly -- the eclass will change |
8 |
> > its category between unused and missing based on the checks. |
9 |
> > |
10 |
> > URL: https://bugs.gentoo.org/417159 |
11 |
> > URL: https://bugs.gentoo.org/417231 |
12 |
> |
13 |
> It's fragile to keep all of these eclass interface definitions hardcoded |
14 |
> in python. For example, the _comprehensive checks are going to start |
15 |
> triggering repoman warnings every time that we add a new function to an |
16 |
> eclass. |
17 |
|
18 |
yes, that's why i picked only ones that are simple/stable |
19 |
|
20 |
> If we keep the eclass interface definitions in the tree with the |
21 |
> eclasses, then it will solve this problem, and it will also be possible |
22 |
> for overlays to fork eclasses and tweak interfaces. |
23 |
|
24 |
if we're going to merge them, might as well do it once rather than still |
25 |
having this problem, but reduced. if i extended the framework to parse the |
26 |
syntax used for documenting the eclass, the problem is reduced to "maintainers |
27 |
that fail to fully document their interfaces will hit problems". but i think |
28 |
that's a good hammer to hit eclass maintainers with. |
29 |
-mike |