Hi, TL;DR: I'd like to make it possible for ebuilds to define additional variables that will be stored in md5-cache. This would be useful for CI and other tooling that right now has to parse ebuilds for other data.
The idea is to add a new incremental ebuild/eclass variable (technical name: QA_EXTRA_CACHE_VARS) that would define additional data to be stored in cache. For example, python*-r1 eclasses would define 'PYTHON_COMPAT', acct-user would define 'ACCT_USER_ID', etc. When regenerating cache, the PM would read this variable, and store the values of all defined variables into md5-cache. As a result, programs needing those variables can get them straight from cache without having to attempt to run or parse ebuilds (which is both slow and prone to bugs). This would benefit e.g. gpyutils that right now need to attempt to parse PYTHON_COMPAT from ebuilds. It would also benefit writing future pkgcheck checks for user/group ID collisions. Notes: - since md5-cache uses key-value format and allows for future extensions, the new values can be added without breaking anything; - md5-cache is not specified in the PMS, and the whole thing can be implemented without need for EAPI bump, - I would like to have this implemented consistently both in Portage and pkgcore, - we will need to clearly define how to dump arrays. What do you think? -- Best regards, Michał Górny
Description: This is a digitally signed message part