| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Ciaran McCreesh wrote: |
| 5 |
| No, it results in a new open() on a file that's elsewhere on disk, which |
| 6 |
| results in two new seeks. You get about fifty seeks per second. |
| 7 |
|
| 8 |
The speed issues aren't really a concern, since the GLEP suggests that |
| 9 |
the ebuild must be sourced anyway. The GLEP allows for a .ebuild-2 file |
| 10 |
to contain EAPI="1". This requires the package manager to source the |
| 11 |
ebuild to find out exactly what EAPI should be being used. The GLEP |
| 12 |
doesn't strictly outline what happens to a .ebuild-1 containing EAPI="2" |
| 13 |
for a PM that supports EAPI="2" (which needs to be addressed before the |
| 14 |
GLEP gets put into action). |
| 15 |
|
| 16 |
It does say a developer should not specify both a pre- and post- source |
| 17 |
EAPI, but the GLEP says that if both exist the post-source one is used. |
| 18 |
~ That means all package managers would have to source the ebuilds. |
| 19 |
|
| 20 |
Personally, as a developer, I don't want to be messing around with yet |
| 21 |
more numbers in the ebuild filenames, and I think it looks ugly. Not |
| 22 |
great arguments, granted. |
| 23 |
|
| 24 |
It also feels like a bad idea to separate information required to |
| 25 |
process the contents of the file from the contents of the file itself. |
| 26 |
P/PN/PV variables are used in clearly defined locations of the file, and |
| 27 |
the script could run under a different name and version (as proved by |
| 28 |
every version bump around). The suggestion seems to be that an ebuild |
| 29 |
could not run under a different EAPI. In that case, the EAPI version |
| 30 |
should be embedded in the contents of the file. |
| 31 |
|
| 32 |
As people have pointed out though, there's no need to rush this |
| 33 |
decision. We're simply not going to achieve backwards compatibility |
| 34 |
forever (we haven't in the past), so why not choose a time period to |
| 35 |
allow for upgrades (6 months, a year?) and implement a new EAPI |
| 36 |
definition mechanism that's present in the file and offers a slightly |
| 37 |
better compromise between the various parties than the current suggestion? |
| 38 |
|
| 39 |
It will require a little more patience, but it offers time for a thought |
| 40 |
out and well designed choice. What's the rush? |
| 41 |
|
| 42 |
Mike 5:) |
| 43 |
-----BEGIN PGP SIGNATURE----- |
| 44 |
Version: GnuPG v2.0.9 (GNU/Linux) |
| 45 |
|
| 46 |
iEYEARECAAYFAkhOpDEACgkQu7rWomwgFXoFvgCeMxSfRiQLEZr3QyT+Bx4b5aNe |
| 47 |
/9EAnicrcCQTXxsliAeM4mdisgjO7abg |
| 48 |
=tGD8 |
| 49 |
-----END PGP SIGNATURE----- |
| 50 |
-- |
| 51 |
gentoo-dev@l.g.o mailing list |
Archives