| 1 | GLEP: 55 |
1 | GLEP: 55 |
| 2 | Title: Use EAPI-suffixed ebuilds (.ebuild-EAPI) |
2 | Title: Use EAPI-suffixed ebuilds (.ebuild-EAPI) |
| 3 | Version: $Revision: 1.1 $ |
3 | Version: $Revision: 1.2 $ |
| 4 | Last-Modified: $Date: 2008/01/05 02:36:35 $ |
4 | Last-Modified: $Date: 2008/01/06 02:39:42 $ |
| 5 | Author: Piotr Jaroszyński <peper@gentoo.org> |
5 | Author: Piotr Jaroszyński <peper@gentoo.org> |
| 6 | Status: Draft |
6 | Status: Draft |
| 7 | Type: Standards Track |
7 | Type: Standards Track |
| 8 | Content-Type: text/x-rst |
8 | Content-Type: text/x-rst |
| 9 | Created: 17-Dec-2007 |
9 | Created: 17-Dec-2007 |
| … | |
… | |
| 26 | |
26 | |
| 27 | The current way of specifying the EAPI in ebuilds is flawed. In order to get the |
27 | The current way of specifying the EAPI in ebuilds is flawed. In order to get the |
| 28 | EAPI the package manager needs to source the ebuild, which itself needs the EAPI |
28 | EAPI the package manager needs to source the ebuild, which itself needs the EAPI |
| 29 | in the first place. Otherwise it imposes a serious limitation, namely every ebuild, |
29 | in the first place. Otherwise it imposes a serious limitation, namely every ebuild, |
| 30 | using any of the future EAPIs, will have to be source'able by old package |
30 | using any of the future EAPIs, will have to be source'able by old package |
| 31 | managers and hence there is no way to: |
31 | managers and hence there is no way to do any of the following: |
| 32 | |
32 | |
| 33 | * Change behaviour of inherit in any way (for example, to extend or change |
33 | * Change the behaviour of inherit in any way (for example, to extend or change |
| 34 | eclass functionality). |
34 | eclass functionality). |
| 35 | |
35 | |
| 36 | * Add new global scope functions in any sane way. |
36 | * Add new global scope functions in any sane way. |
| 37 | |
37 | |
| 38 | * Extend versioning rules in an EAPI - for example, addition of the scm |
38 | * Extend versioning rules in an EAPI - for example, addition of the scm |
| … | |
… | |
| 53 | Proposed solution |
53 | Proposed solution |
| 54 | ================= |
54 | ================= |
| 55 | |
55 | |
| 56 | The proposed solution is to use EAPI-suffixed file extensions for ebuilds. This |
56 | The proposed solution is to use EAPI-suffixed file extensions for ebuilds. This |
| 57 | allows package managers to trivially read the EAPI from the ebuild filename. It |
57 | allows package managers to trivially read the EAPI from the ebuild filename. It |
| 58 | is also backward compatible, because currently ebuilds are recognised by the |
58 | is also backwards compatible, because currently ebuilds are recognised by the |
| 59 | ``.ebuild`` file extension and hence EAPI-suffixed ebuilds are simply ignored by |
59 | ``.ebuild`` file extension and hence EAPI-suffixed ebuilds are simply ignored by |
| 60 | the package managers. |
60 | the package managers. |
| 61 | |
61 | |
| 62 | |
62 | |
| 63 | Specification |
63 | Specification |
| … | |
… | |
| 85 | in such cases. |
85 | in such cases. |
| 86 | |
86 | |
| 87 | Examples: |
87 | Examples: |
| 88 | |
88 | |
| 89 | * ``pkg-1.ebuild``, no EAPI set inside the ebuild |
89 | * ``pkg-1.ebuild``, no EAPI set inside the ebuild |
| 90 | pre-source EAPI defaults 0, post-source EAPI defaults to pre-source EAPI. |
90 | pre-source EAPI defaults to 0, post-source EAPI defaults to pre-source EAPI. |
| 91 | EAPI 0 is used. |
91 | EAPI 0 is used. |
| 92 | |
92 | |
| 93 | * ``pkg-2.ebuild-1``, no EAPI set inside the ebuild |
93 | * ``pkg-2.ebuild-1``, no EAPI set inside the ebuild |
| 94 | pre-source EAPI is 1, post-source EAPI defaults to pre-source EAPI. |
94 | pre-source EAPI is 1, post-source EAPI defaults to pre-source EAPI. |
| 95 | EAPI 1 is used. |
95 | EAPI 1 is used. |
| … | |
… | |
| 103 | EAPI 1 is used, but note that one should **never** explicitly set both |
103 | EAPI 1 is used, but note that one should **never** explicitly set both |
| 104 | EAPIs to different values. |
104 | EAPIs to different values. |
| 105 | |
105 | |
| 106 | * ``pkg-5.ebuild-2``, no EAPI set inside the ebuild, package manager not supporting EAPI 2 |
106 | * ``pkg-5.ebuild-2``, no EAPI set inside the ebuild, package manager not supporting EAPI 2 |
| 107 | pre-source EAPI is 2, post-source EAPI is never checked. |
107 | pre-source EAPI is 2, post-source EAPI is never checked. |
| 108 | ebuild masked because of the unsupported pre-source EAPI. |
108 | ebuild is masked because of the unsupported pre-source EAPI. |
| 109 | |
109 | |
| 110 | * ``pkg-6.ebuild``, ``EAPI="2"``, package manager not supporting EAPI 2 |
110 | * ``pkg-6.ebuild``, ``EAPI="2"``, package manager not supporting EAPI 2 |
| 111 | pre-source EAPI defaults to 0, post-source EAPI is 2 (assuming the |
111 | pre-source EAPI defaults to 0, post-source EAPI is 2 (assuming the |
| 112 | package manager didn't die when sourcing the ebuild thinking that EAPI 0 |
112 | package manager didn't die when sourcing the ebuild thinking that EAPI 0 |
| 113 | is used). |
113 | is used). |
| 114 | ebuild masked because of the unsupported post-source EAPI. |
114 | ebuild is masked because of the unsupported post-source EAPI. |
| 115 | |
115 | |
| 116 | Note that it is still not permitted to have more than one ebuild with equal |
116 | Note that it is still not permitted to have more than one ebuild with equal |
| 117 | category, package name, and version. Although it would have the advantage of |
117 | category, package name, and version. Although it would have the advantage of |
| 118 | allowing to provide backward compatible ebuilds, it would introduce problems |
118 | allowing authors to provide backwards compatible ebuilds, it would introduce |
| 119 | too. The first is the requirement to have strict EAPI ordering, the second is |
119 | problems too. The first is the requirement to have strict EAPI ordering, the |
| 120 | ensuring that all the ebuilds for a single category/package-version are |
120 | second is ensuring that all the ebuilds for a single category/package-version |
| 121 | equivalent, i.e. installing any of them has exactly the same effect to the |
121 | are equivalent, i.e. installing any of them has exactly the same effect on a |
| 122 | system. |
122 | given system. |
| 123 | |
123 | |
| 124 | Application |
124 | Application |
| 125 | =========== |
125 | =========== |
| 126 | |
126 | |
| 127 | Note that the developers should only set the pre-source EAPI. The process |
127 | Note that the developers should only set the pre-source EAPI. The process |
| … | |
… | |
| 137 | There were some other solutions proposed on the mailing list: |
137 | There were some other solutions proposed on the mailing list: |
| 138 | |
138 | |
| 139 | * Set the EAPI inside the ebuild in a way that makes it easy to fetch it |
139 | * Set the EAPI inside the ebuild in a way that makes it easy to fetch it |
| 140 | * Doesn't meet the backward compatibility requirement. |
140 | * Doesn't meet the backward compatibility requirement. |
| 141 | * Isn't forward compatible either. |
141 | * Isn't forward compatible either. |
| 142 | * Could be confusing as ebuilds, and not without a reason, are |
142 | * Could be confusing as ebuilds are considered bash scripts and this |
| 143 | considered bash scripts and this would impose additional restrictions. |
143 | would impose additional restrictions on the ebuild format. |
| 144 | |
144 | |
| 145 | * Do the above and change the ebuild extension to ``.ebuild-ng`` |
145 | * Do the above and change the ebuild extension to ``.ebuild-ng`` |
| 146 | * Meets the backward compatibility requirement. |
146 | * Meets the backward compatibility requirement. |
| 147 | * Still can be confusing. |
147 | * Still can be confusing. |
| 148 | * Isn't really forward compatible. What would be after ``.ebuild-ng``? |
148 | * Isn't really forward compatible. What would be after ``.ebuild-ng``? |
Parent Directory
| 
Revision Log
| 
Patch