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