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.


- 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

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to