| 1 |
On Thursday 28 May 2009 20:04:18 Ciaran McCreesh wrote: |
| 2 |
> On Thu, 28 May 2009 18:56:00 +0100 |
| 3 |
> |
| 4 |
> Roy Bamford <neddyseagoon@g.o> wrote: |
| 5 |
> > As I understand this, it may add six seconds to an emerge world while |
| 6 |
> > the dep tree is calculated. Lets say it takes an hour to do emerge |
| 7 |
> > world, the time has increased from 3600 seconds to 3606 seconds or a |
| 8 |
> > trivial 0.1666667% |
| 9 |
> |
| 10 |
> Interactive time is important. If it were adding those extra seconds to |
| 11 |
> the build, no-one would care. But it's not. It's adding them to when |
| 12 |
> the user's sitting at the screen waiting for results. |
| 13 |
|
| 14 |
So how about we improve the structure instead of trying to patch up some |
| 15 |
hotspots? |
| 16 |
For example a readonly repository would guarantee that the cache is always |
| 17 |
consistent. Then you can add some smart indexes, and suddenly you're no longer |
| 18 |
limited by IO but by CPU. Last time I saw someone try the raw metadata for all |
| 19 |
ebuilds was smaller than 5MB, which can be read by a modern harddisk in under |
| 20 |
half a second - doesn't that sound quite motivating? |
| 21 |
|
| 22 |
> > You mean 0.3% (or less) of the emerge world time? |
| 23 |
> |
| 24 |
> No, he means 50% of pretend time when you're sitting there waiting to |
| 25 |
> see what's going to happen. |
| 26 |
|
| 27 |
So fix the diseases instead of doctoring around some symptoms ... |
| 28 |
|
| 29 |
> > I am against *all* and any metadata in the filename. Today, GLEP 55 |
| 30 |
> > proposes the add the EAIP, tomorrow, there will be something else, |
| 31 |
> > the day after another thing ... and all because allowing EAPI set the |
| 32 |
> > precedent. |
| 33 |
> |
| 34 |
> No there won't be. There is no slippery slope. |
| 35 |
And there's no intention of building a wall ;) |
| 36 |
|
| 37 |
> Also, PV and PN are already in the filename. |
| 38 |
That is needed to keep the filename reasonably unique. If you know of a nicer |
| 39 |
way to uniqueify it feel free to tell us ... |
| 40 |
> |
| 41 |
> > You also make the error of assuming that with eapi-in-ebuild the |
| 42 |
> > currently suggested approaches to extracting the EAPI from the ebuild |
| 43 |
> > are the best and remain unchanged. Thats unlikely, as not a lot of |
| 44 |
> > work has been done it yet. |
| 45 |
> |
| 46 |
> It is the best. If we're requiring EAPI before trying to parse PV, all |
| 47 |
> the EAPIs have to be known to do any ordering. |
| 48 |
|
| 49 |
... and why the [censored] would we want that then? |
| 50 |
|
| 51 |
I mean, seriously. That is a circular argument. |
| 52 |
It also ignores everything said by Roy, denying even the possibility of an |
| 53 |
alternative. Last time I saw that style of argumentation was in a documentary |
| 54 |
that showed how darwinism couldn't be right (and still those people believe in |
| 55 |
the flu. Ha.) |
| 56 |
|
| 57 |
It would help if you would tolerate other opinions (or even the possibility |
| 58 |
that other people may have opinions that do not agree with you). Roy, as an |
| 59 |
experienced engineer and as far as I know project manager, might have a good |
| 60 |
idea or two about how to make things not blow up, and it might be in our best |
| 61 |
interest to listen to him for a minute or two. |
Archives