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. -- Thanks, Zac
signature.asc
Description: OpenPGP digital signature
