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
On 7/25/19 4:29 PM, Michał Górny wrote:
>>
>> * In the md5-cache entry, maybe use a common prefix like EXT_ for the
>> extra keys in order to distinguish them from normal keys.
>
> Yeah, I was thinking of something like '__ext_foo', or '__ext[foo]'.
>
What are the pros/cons of this? The names re
On Thu, 2019-07-25 at 12:57 -0700, Zac Medico wrote:
> 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
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
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_