| 1 |
-----BEGIN PGP SIGNED MESSAGE-----
|
| 2 |
Hash: SHA1
|
| 3 |
|
| 4 |
On Thu, 28 May 2009 18:56:00 +0100
|
| 5 |
Roy Bamford <neddyseagoon@g.o> wrote:
|
| 6 |
> As I understand this, it may add six seconds to an emerge world while |
| 7 |
> the dep tree is calculated. Lets say it takes an hour to do emerge |
| 8 |
> world, the time has increased from 3600 seconds to 3606 seconds or a |
| 9 |
> trivial 0.1666667% |
| 10 |
|
| 11 |
Interactive time is important. If it were adding those extra seconds to
|
| 12 |
the build, no-one would care. But it's not. It's adding them to when
|
| 13 |
the user's sitting at the screen waiting for results.
|
| 14 |
|
| 15 |
> You mean 0.3% (or less) of the emerge world time? |
| 16 |
|
| 17 |
No, he means 50% of pretend time when you're sitting there waiting to
|
| 18 |
see what's going to happen.
|
| 19 |
|
| 20 |
> I am against *all* and any metadata in the filename. Today, GLEP 55 |
| 21 |
> proposes the add the EAIP, tomorrow, there will be something else, |
| 22 |
> the day after another thing ... and all because allowing EAPI set the |
| 23 |
> precedent. |
| 24 |
|
| 25 |
No there won't be. There is no slippery slope. Also, PV and PN are
|
| 26 |
already in the filename.
|
| 27 |
|
| 28 |
> You also make the error of assuming that with eapi-in-ebuild the |
| 29 |
> currently suggested approaches to extracting the EAPI from the ebuild |
| 30 |
> are the best and remain unchanged. Thats unlikely, as not a lot of |
| 31 |
> work has been done it yet. |
| 32 |
|
| 33 |
It is the best. If we're requiring EAPI before trying to parse PV, all
|
| 34 |
the EAPIs have to be known to do any ordering.
|
| 35 |
|
| 36 |
- --
|
| 37 |
Ciaran McCreesh
|
| 38 |
-----BEGIN PGP SIGNATURE-----
|
| 39 |
Version: GnuPG v2.0.9 (GNU/Linux)
|
| 40 |
|
| 41 |
iEYEARECAAYFAkoe0iQACgkQ96zL6DUtXhEUrQCgoFztweuK3QRU2Ff0b0r6Otri
|
| 42 |
D8sAoLSF9hv+4k5xG+k69s8z8NanNN+I
|
| 43 |
=yO/c
|
| 44 |
-----END PGP SIGNATURE----- |
Archives