| 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.4 $ |
3 | Version: $Revision: 1.5 $ |
| 4 | Last-Modified: $Date: 2009/05/17 17:00:30 $ |
4 | Last-Modified: $Date: 2009/05/17 20:56:53 $ |
| 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 |
| … | |
… | |
| 215 | problems too. The first is the requirement to have strict EAPI ordering, the |
215 | problems too. The first is the requirement to have strict EAPI ordering, the |
| 216 | second is ensuring that all the ebuilds for a single category/package-version |
216 | second is ensuring that all the ebuilds for a single category/package-version |
| 217 | are equivalent, i.e. installing any of them has exactly the same effect on a |
217 | are equivalent, i.e. installing any of them has exactly the same effect on a |
| 218 | given system. |
218 | given system. |
| 219 | |
219 | |
|
|
220 | Also note that it is not a new restriction. It is already possible to illegally |
|
|
221 | have multiple versions with different EAPIs as e.g. ``1.0 == 1.00 == 1.00-r0`` |
|
|
222 | and hence you could have ``foo-1.0.ebuild`` with EAPI X and ``foo-1.00.ebuild`` |
|
|
223 | with EAPI Y. |
|
|
224 | |
| 220 | Summary of ideas |
225 | Summary of ideas |
| 221 | ================ |
226 | ================ |
| 222 | |
227 | |
| 223 | EAPI-suffixed ebuilds (proposed solution) |
228 | EAPI-suffixed ebuilds (proposed solution) |
| 224 | ----------------------------------------- |
229 | ----------------------------------------- |
| … | |
… | |
| 256 | Performance decrease comes from the fact that with version format changes in the |
261 | Performance decrease comes from the fact that with version format changes in the |
| 257 | picture package managers need EAPI to parse the ebuild's version. That means that merely |
262 | picture package managers need EAPI to parse the ebuild's version. That means that merely |
| 258 | picking the best version of a package requires loading EAPI (from cache or the |
263 | picking the best version of a package requires loading EAPI (from cache or the |
| 259 | ebuild) for each available ebuild. |
264 | ebuild) for each available ebuild. |
| 260 | |
265 | |
|
|
266 | Here is more or less how the package manager figures out the best available |
|
|
267 | version for a package with N versions available. |
|
|
268 | |
|
|
269 | * EAPI in the filename |
|
|
270 | |
|
|
271 | * Read the directory containing the package - readdir() |
|
|
272 | * For each ebuild, read its EAPI and using that parse its version - no I/O |
|
|
273 | * Sort the versions - no I/O |
|
|
274 | * Going down from the highest to the lowest version |
|
|
275 | |
|
|
276 | * Get the metadata from cache - 2 x stat() + read() |
|
|
277 | * break if the version is visible |
|
|
278 | |
|
|
279 | * EAPI in the ebuild |
|
|
280 | |
|
|
281 | * Read the directory containing the package - readdir() |
|
|
282 | * For each ebuild load its metadata from cache to get its EAPI - N x (2 x stat() + read()) |
|
|
283 | * Sort the versions - no I/O |
|
|
284 | * Going down from the highest to the lowest version |
|
|
285 | |
|
|
286 | * (metadata is already loaded) - no I/O |
|
|
287 | * break if the version is visible - no I/O |
|
|
288 | |
|
|
289 | The difference is in for how many versions the package manager needs to hit |
|
|
290 | cache. With EAPI in the ebuild it needs to do that for all versions, with EAPI |
|
|
291 | in the filename it depends on versions visibility. |
|
|
292 | For example, package foo has versions 1, 2, 3, 4, 5 and 6. 6 is masked, 5 is |
|
|
293 | ~arch and 1,2,3 and 4 are arch. Say, the user accepts only arch for this |
|
|
294 | package. With EAPI in the filename it will read metadata only for versions |
|
|
295 | 6, 5 and 4. With EAPI in the ebuild it needs to load metadata for all versions. |
|
|
296 | |
|
|
297 | It's hard to say what's the avarage case, but surely the worst case scenario |
|
|
298 | (when only the lowest version is visible) is uncommon. |
| 261 | |
299 | |
| 262 | Easily fetchable EAPI inside the ebuild and one-time extension change |
300 | Easily fetchable EAPI inside the ebuild and one-time extension change |
| 263 | --------------------------------------------------------------------- |
301 | --------------------------------------------------------------------- |
| 264 | |
302 | |
| 265 | Properties: |
303 | Properties: |
Parent Directory
| 
Revision Log
| 
Patch