| 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 |
Archives