| 1 |
Ciaran McCreesh wrote: |
| 2 |
> On Mon, 23 Feb 2009 18:47:07 -0500 |
| 3 |
> Richard Freeman <rich0@g.o> wrote: |
| 4 |
>> It seems like we could be up to ebuild-kde4-3.2 in six months. |
| 5 |
> |
| 6 |
> Why on earth do people think that? Of all the crazy being thrown |
| 7 |
> around, this is the only one wearing a tutu. |
| 8 |
> |
| 9 |
|
| 10 |
I suppose I'm exaggerating a little deliberately to make a point. It |
| 11 |
isn't so much that I don't think that people designing the extensions |
| 12 |
won't use sense, but that we're still potentially facing multiple new |
| 13 |
file extensions per year. Maybe not 15, but certainly 1-3. That can |
| 14 |
add up fast. If we had been doing this all along then we'd probably |
| 15 |
expect there to be upwards of 10-20 file extensions in portage today. |
| 16 |
|
| 17 |
It just seems like it isn't the best solution. You can get the same |
| 18 |
effect by just sticking something in a comment line a few lines into the |
| 19 |
ebuild in a fixed position. Sure, the file might need to be read twice, |
| 20 |
but unless the reading takes place widely separated in time the file is |
| 21 |
going to be in the cache the second time around. With proper caching |
| 22 |
you only need to scan files that have changed - we can't have that many |
| 23 |
daily commits, can we? |
| 24 |
|
| 25 |
I'll probably refrain from commenting further - I trust the council to |
| 26 |
weigh all the options and go with whatever makes the most sense. |
| 27 |
However, I did want to make it clear that I don't think that the folks |
| 28 |
advocating this approach are out to release 47 EAPI releases per year or |
| 29 |
anything... |
Archives