| 1 |
On Tue, Apr 9, 2013 at 1:57 AM, Michał Górny <mgorny@g.o> wrote: |
| 2 |
> On Mon, 8 Apr 2013 23:20:28 -0600 |
| 3 |
> Ryan Hill <dirtyepic@g.o> wrote: |
| 4 |
> |
| 5 |
>> If someone else wants to try and improve the situation, please feel free. |
| 6 |
> |
| 7 |
> Just to be sure -- would you be ok if we tried to inline some |
| 8 |
> of the eclass code into the ebuilds (future versions/revbumps)? |
| 9 |
|
| 10 |
Honestly, when you're talking about small numbers of packages I think |
| 11 |
this is the only thing which is sustainable. |
| 12 |
|
| 13 |
Eclasses should perform generic functions which have well-defined |
| 14 |
inputs and outputs which are broadly applicable. When you start |
| 15 |
building them for small groups of packages you start to run into |
| 16 |
situations like this. |
| 17 |
|
| 18 |
If your ebuilds basically just contain KEYWORDS and little more then |
| 19 |
the eclasses are doing too much for sure. |
| 20 |
|
| 21 |
I can see the need for cases like python/perl/etc eclasses when you |
| 22 |
have a large number of packages which need similar logic, but if the |
| 23 |
inputs/outputs of the functions change then the functions should |
| 24 |
change names. So, rather than overriding src_prepare and then doing a |
| 25 |
bunch of logic to figure out which of 12 different upstream packaging |
| 26 |
approaches was in use it should just have 12 different functions and |
| 27 |
the ebuild should call the right one from its own src_prepare. Then |
| 28 |
you can actually deprecate functions that are no longer needed, and |
| 29 |
not change functions that are being used in stable (or if you change |
| 30 |
them you're less likely to break them because each function only |
| 31 |
operates on a well-defined set of inputs and outputs). |
| 32 |
|
| 33 |
Bottom line is that automagic eclasses can sometimes be as bad as |
| 34 |
automagic build systems, for most of the same reasons. |
| 35 |
|
| 36 |
And that isn't even getting into the fact that we don't really have |
| 37 |
any mechanism for getting rid of eclasses. All that crufty code just |
| 38 |
collects. |
| 39 |
|
| 40 |
(I'm sure I missed a few good uses for eclasses above, but I'd still |
| 41 |
tend to say that if an eclass function is accepting data in many |
| 42 |
different formats it is probably doing too much.) |
| 43 |
|
| 44 |
Rich |
Archives