Re: [gentoo-portage-dev] [RFC] Adding extra vars to md5-cache, for QA&tooling purposes

[Fabian Groffen]

Hi,

On 25-07-2019 14:20:50 +0200, 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.

Only downside I can think of, is a diskspace increase for the md5-cache.
Not sure if this is going to be substantial, but given things like
PYTHON_COMPAT, perhaps a quick calculation of extra "cost" can be made.
Should diskspace become a problem, one could consider to use a separate
file/dir, that users could rsync-exclude, since Portage won't need it to
operate properly.

Thanks,
Fabian

>
>
> 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
>



-- 
Fabian Groffen
Gentoo on a different level