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

[Brian Harring]

On Sat, Jan 28, 2006 at 12:47:43AM +0900, Jason Stubbs wrote:
> On Tuesday 24 January 2006 23:52, Marius Mauch wrote:
> > On Mon, 23 Jan 2006 14:08:00 -0800
> > Brian Harring <ferringb@g.o> wrote:
> > > Well, if you disagreed with the original response, continue the
> > > conversation prior to commiting- otherwise we see a commit, then a
> > > rebuttal a few hours later.  Not really how things should go for a
> > > contested piece of code (at least when the only two to weigh in our
> > > flat out opposed on it)- especially if the code's effect is
> > > nontrivial and it hasn't had any actual peer review (only comment was
> > > on your algo).
> >
> > Interesting, you now count for two people? Or who is this second person
> > you're talking of? I still think you're making more out of this than it
> > really is. Also there really isn't a point in discussing a difference in
> > opinion IMO, such attempts lead nowhere. I considered your comment, but
> > couldn't come up with a reason why a theoretical issue should hold this
> > up.
>
> Even if Brian can't count,
Bah, you two can't count. :p

Marius and myself weighing on this == 2 people
Marius, you, myself commenting == 3 people


> a single (reasonable) voice should be enough to
> prevent moving forward. That single voice could have said everything that
> other possible responders were thinking of saying negating the need for
> further responses.
>
> So what's happening with this? As far as I understand it, there's a high
> probability of incorrect file generation. Should "vdbkeys" be pulled out of
> emaint's "modules" var until next release?

I don't really want to see the current form go out; my 
suggestion/proposed course would be backing it out (literally, 
revert), extend emaint so it loads checks on the fly (not horrid to 
do), and distribute the check externally, at least for the interim.

Fixing up the check requires pulling filter-env back, which I'll be 
doing this weekend.  Not sure of peoples opionion on this one, but 
filter-env *is* used in any ebd based portage, so I'd prefer it were 
external- no point in having this check and bcportage bundling their 
own copy of filter-env.

My two cents on it; the check's logic as I've stated is faulty, and 
can match in unattended places due to lack of state which is 
disconcerting, further disconcerting is the inability of the code to 
properly grab value settings that are $'' with newlines embedded.

Roughly,

#!/bin/sh
eval $(bzcat environment.bz2 | filter-env -f '.*' -v 'BASH.*' )
for __x in "$@"; do
	echo __x=$(echo "${__x}" | tr '\n,\r,\t' ' , , ')
done

is what's required.
~harring