| 1 |
On Thu, Jun 19, 2014 at 6:05 PM, Steven J. Long |
| 2 |
<slong@××××××××××××××××××.uk> wrote: |
| 3 |
> So which way do you actually prefer? |
| 4 |
> |
| 5 |
> You appear to be arguing for, and implementing, common code by EAPI, |
| 6 |
> in the rest of your mail. Since that's always been the point of |
| 7 |
> them, based on developer consensus about what is truly essential, |
| 8 |
> and what is only needed for a subset of the tree, that's fine by me. |
| 9 |
|
| 10 |
This is all becoming moot since the Council just voted on this earlier |
| 11 |
this week, nearly unanimously bringing in user patches. However, I |
| 12 |
believe he was advocating going with an EAPI in this case, but |
| 13 |
offering alternatives. |
| 14 |
|
| 15 |
While brainstorming the options I was thinking that you could almost |
| 16 |
have an EAPI-like eclass. That is, instead of declaring an EAPI every |
| 17 |
ebuild could just source an EAPI-foo eclass which basically does the |
| 18 |
same thing. Of course, this would be somewhat less flexible than what |
| 19 |
we do today - if we went as far as being able to determine EAPI |
| 20 |
without sourcing an ebuild (no, I'm not bringing back that debate now) |
| 21 |
then having EAPI in the PM lets you change the ebuild format in almost |
| 22 |
entirely arbitrary ways over time. |
| 23 |
|
| 24 |
There is nothing wrong with playing devil's advocate in a thread like |
| 25 |
this. Hopefully the Council members can weigh the arguments on their |
| 26 |
own. :) |
| 27 |
|
| 28 |
Rich |
Archives