| 1 |
On Wed, 2009-02-25 at 00:21 +0200, Petteri Räty wrote: |
| 2 |
> get opinions [..] to get some idea what the general developer pool thinks. |
| 3 |
> only allowed to post a single reply to this thread |
| 4 |
|
| 5 |
Thank you for that, I usually don't follow long threads, so apologies if |
| 6 |
things have been discussed already. |
| 7 |
|
| 8 |
Basically, I'm all for having GLEP55 "as good as possible" in favour of |
| 9 |
"as soon as possible" before implementation, even if it fits my |
| 10 |
thoughts quite good already (see below). |
| 11 |
|
| 12 |
> 2) EAPI in file extension |
| 13 |
|
| 14 |
IMO, this should define *how* to read the *final* EAPI from the ebuild. |
| 15 |
The *how* does not necessarily mean to /source/ the ebuild, so the terms |
| 16 |
"pre-source EAPI" and "post-source EAPI" IMHO are too strongly focussing |
| 17 |
on "(bash)> source $EBUILD" when used in a generic GLEP. Eventually, the |
| 18 |
"pre-source" EAPI could be called "major" EAPI, and the |
| 19 |
"post-source" EAPI could be called "major.minor" EAPI (see below). |
| 20 |
|
| 21 |
The "EAPI in file extension" also should define the filename-part of the |
| 22 |
versioning rules. |
| 23 |
|
| 24 |
> a) .ebuild-<eapi> |
| 25 |
> c) .<eapi>.<new extension> |
| 26 |
> - ignored by current Portage |
| 27 |
> b) .<eapi>.ebuild |
| 28 |
> - current Portage does not work with this |
| 29 |
|
| 30 |
"ignored by current portage" is an important point for me to |
| 31 |
*theorethically* guarantee for a possible upgrade path even over long |
| 32 |
time. |
| 33 |
|
| 34 |
> 3) EAPI in locked down place in the ebuild |
| 35 |
|
| 36 |
This "lock down" should be done by "EAPI in file extension" above. |
| 37 |
"lock down" can mean any of: "post-source (real bash-source)", |
| 38 |
"self-parse (grep?)", "fixed-byte/line-offset", "..." |
| 39 |
|
| 40 |
My thoughts are to split EAPI into several levels (rename them however |
| 41 |
you like): |
| 42 |
|
| 43 |
entry-point: |
| 44 |
Specifies how to read the "filename-scope" EAPI. |
| 45 |
|
| 46 |
filename-scope EAPI: |
| 47 |
Think as "major" EAPI. |
| 48 |
Specifies the filename-part of versioning rules. |
| 49 |
Specifies how to read the "global-scope" EAPI (can, but |
| 50 |
eventually should not require bash-sourcing the ebuild). |
| 51 |
May allow to not define "minor", assuming "$major.0.0" then. |
| 52 |
|
| 53 |
global-scope EAPI: |
| 54 |
Think as "$major.minor" EAPI. |
| 55 |
May specify how to define additional versioning rules. |
| 56 |
Specifies how to define metadata information. |
| 57 |
Specifies which metadata information is |
| 58 |
required/optional/cached/... Specifies how to utilize external |
| 59 |
resources (eclasses). |
| 60 |
Specifies which/how actions can/must be defined (pkg_*, src_* |
| 61 |
functions). |
| 62 |
Specifies how to read the "local-scope" EAPI. |
| 63 |
May allow to not define "micro", assuming "$major.$minor.0" |
| 64 |
then. |
| 65 |
May disallow a "local-scope" EAPI, specifies it instead. |
| 66 |
|
| 67 |
local-scope EAPI: |
| 68 |
Think as "$major.$minor.micro" EAPI. |
| 69 |
Specifies which PM-functions are available for use in actions |
| 70 |
(fex 'doman' inside src_install). |
| 71 |
May be specified as part of "minor" EAPI. |
| 72 |
|
| 73 |
Thanks! |
| 74 |
/haubi/ |
| 75 |
-- |
| 76 |
Michael Haubenwallner |
| 77 |
Gentoo on a different level |
Archives