Re: [gentoo-portage-dev] making aux_get more usable for vardbapi

[Brian Harring]

On Tue, Jan 10, 2006 at 07:53:04PM +0100, Marius Mauch wrote:
> Currently vardbapi.aux_get only works for a subset of all auxdbkeys, as
> some like KEYWORDS or DESCRIPTIOn aren't stored in vdb directly.
> They are however stored in environment.bz2, but not accessible
> there.
> This is unintuitive and limits tools like equery or my own auxget
> and metascan tools in their usability.
>
> There are two solutions to this problem:
> a) enhance vardbapi.aux_get so it can use environment.bz2
> b) store more keys in vdb
>
> Now there is a tradeoff to made: a) doesn't need space but is slow
> while b) is fast but needs space, both in non-trivial amounts (runtime
> increased from 1s to 9s for a metascan -i run and from 0.5s to 0.8s
> for auxget -i, haven't actually checked the size increase, expect
> somewhere between 1 and 10 megabytes on a typical install).
>
> I'm attaching a patch that implements both (each in it's own hunk) as
> well as a new emaint option to create the missing entries offline.
>
> A not so obvious issue with a) is that due to the recent
> storage optimizations (empty entries not being stored) it's worse than
> I originally expected, as any entry missing a file will be looked up in
> env.bz2 instead. Only way to avoid that would be to add special casing
> in aux_get which I really dislike.
>
> Opinions?
Use filter-env to pull the var out.

Regex you've got there allows for pulling the wrong text- recall, ebd 
originally was doing grep based filtering (regex).  Had to rewrite 
that in a major hurry since bash syntax (specifically here ops) forces 
you to track state/constructs rather then just a regex...

Aside from that, while it's annoying, should do a one time pull- if a 
var is in a whitelist of "can be pulled from env", we pull all missing 
vars *once*.  My opinion, at least.
~harring