On 7/25/19 5:20 AM, Michał Górny wrote:
> 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?

Sounds good. Some thoughts:

* Maybe omit QA from the variable name, since it can be could be
generally useful for things that are unrelated to QA.

* In the md5-cache entry, maybe use a common prefix like EXT_ for the
extra keys in order to distinguish them from normal keys.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to