1 |
Hi, |
2 |
|
3 |
TL;DR: I'd like to make it possible for ebuilds to define additional |
4 |
variables that will be stored in md5-cache. This would be useful for CI |
5 |
and other tooling that right now has to parse ebuilds for other data. |
6 |
|
7 |
|
8 |
The idea is to add a new incremental ebuild/eclass variable (technical |
9 |
name: QA_EXTRA_CACHE_VARS) that would define additional data to be |
10 |
stored in cache. For example, python*-r1 eclasses would define |
11 |
'PYTHON_COMPAT', acct-user would define 'ACCT_USER_ID', etc. |
12 |
|
13 |
When regenerating cache, the PM would read this variable, and store |
14 |
the values of all defined variables into md5-cache. As a result, |
15 |
programs needing those variables can get them straight from cache |
16 |
without having to attempt to run or parse ebuilds (which is both slow |
17 |
and prone to bugs). |
18 |
|
19 |
This would benefit e.g. gpyutils that right now need to attempt to parse |
20 |
PYTHON_COMPAT from ebuilds. It would also benefit writing future |
21 |
pkgcheck checks for user/group ID collisions. |
22 |
|
23 |
|
24 |
Notes: |
25 |
|
26 |
- since md5-cache uses key-value format and allows for future |
27 |
extensions, the new values can be added without breaking anything; |
28 |
|
29 |
- md5-cache is not specified in the PMS, and the whole thing can be |
30 |
implemented without need for EAPI bump, |
31 |
|
32 |
- I would like to have this implemented consistently both in Portage |
33 |
and pkgcore, |
34 |
|
35 |
- we will need to clearly define how to dump arrays. |
36 |
|
37 |
|
38 |
What do you think? |
39 |
|
40 |
-- |
41 |
Best regards, |
42 |
Michał Górny |