Re: [gentoo-portage-dev] making aux_get more usable for vardbapi
On Fri, Jan 27, 2006 at 10:19:50AM -0800, Brian Harring wrote:
> #!/bin/sh
> eval $(bzcat environment.bz2 | filter-env -f '.*' -v 'BASH.*' )
> for __x in "$@"; do
> echo __x=$(echo "${__x}" | tr '\n,\r,\t' ' , , ')
echo ${__x}=$(echo "${!__x}" | tr '\n,\r,\t' ' , , ')
> done
Change above would result in a slightly more useful output ;)
~harring
pgp5kZXG1tfAv.pgp
Description: PGP signature
Re: [gentoo-portage-dev] making aux_get more usable for vardbapi
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 <[EMAIL PROTECTED]> 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
pgpbXQSLQfrsi.pgp
Description: PGP signature
Re: [gentoo-portage-dev] making aux_get more usable for vardbapi
On Tuesday 24 January 2006 23:52, Marius Mauch wrote: > On Mon, 23 Jan 2006 14:08:00 -0800 > Brian Harring <[EMAIL PROTECTED]> 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, 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? -- Jason Stubbs -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] making aux_get more usable for vardbapi
On Mon, 23 Jan 2006 14:08:00 -0800
Brian Harring <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 23, 2006 at 07:44:44PM +0100, Marius Mauch wrote:
> > On Mon, 23 Jan 2006 03:47:11 -0800
> > Can't follow your thinking here. As said, the code won't corrupt any
> > data, at worst it will tell the user that it couldn't extract some
> > keys (and even that only if there would be such a stupid case which
> > itself has a chance of like 10^-10 or so, or can you name a single
> > case?).
>
> Yeah, any extension of your code to pick up EAPI is going to false
> positive on somewhere around a quarter of my vdb nodes- I use a
> debug function from my bashrc for prefix testing (holdover from eapi
> testing days). Why? Because the eapi var didn't exist (thus no env
> assignment), the only possible match is in the middle of a here op-
>
> debug_dump() {
> ...
> echo <<&2
> EAPI="${EAPI-unset}"
> PF="$PF"
> CATEGORY="$CATEGORY"
> HERE
> ...
> }
>
> Setting EAPI to unset strikes me as corruption here, because now
> portage will *never* do anything with that vdb node- the eapi differs
> from what it supports (it's been set to effectively a random value),
> thus I have to fix the vdb entry myself if I ever want to get rid of
> it.
>
> Guessing the response on that one is "well, you're using the bashrc",
> and yes, I am- the vdb code should be *robust*, not choking on a
> users debug code.
Not even trying to comment on this one.
> > So what package contains filter-env then?
>
> Portage- been in cvs/svn for over a year now :)
Not in trunk or any release (except the alpha snapshot). And I'm not
going to blindly copy unknown code from completely different codebases
and later be blamed for doing it improperly.
> > > Aside from that, if the code is in debate (as this is), I really
> > > don't think it should get slid into svn 2 weeks later effectively
> > > unchanged- didn't write that original email just for the hell of
> > > it :)
> >
> > As said, I disagree with your assessment of the situation. If you
> > can name a single case where the code "breaks" or filter-env hits
> > the tree I might reconsider, but not before.
>
> 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.
> Issues with the code.
Now we're getting somewhere.
> 1) Scans for metadata that didn't exist at the time of the ebuild's
> installation, only possible match is unintended. Not good.
Not really sure what that's supposed to mean, assuming you mean that
nodes will lack SRC_URI/HOMEPAGE/... from env.bz2 is about as likely as
here doc statements containing them (and indicates a broken package
anyway).
> 2) your code is breaking upon *all* newlines, regardless if it's
> in the middle of a variable assignment. Yes, bash does use $'' for
> assignment, but you're relying (hoping really) that the variable has
> been filtered by python portage and the ebuild defined var is
> stomped. This is a bad idea- description comes to mind. Your code
> seems to be aware of this possibility also, since it's doing rather
> loose quote filtering.
Have to think about this.
> 3) Stop using regex all over the place. split/join is a helluva lot
> faster, and collapses that nasty regex that attempts to remove
> whitespace down to two lines (a one time translate, and the
> split/join to kill whitespace).
Ok (cosmetics).
> 4) Code specifically tries to find, and remove variable chars-
> this is *really* the wrong thing to do. If you're trying to work
> around catching a var reference, either your parsing screwed up, or
> you're mangling a DESCRIPTION value that you shouldn't be hosing.
define "variable chars", otherwise doesn't make sense.
> 5) hardcoded vdb.
> 6) Non root aware VDB.
Ok (trivial)
> 7) Only is aware of environment.bz2- older portage versions differed
> in this afaik (I *do* know PORT_ENV_FILE overloading for ebd I had to
> address this case already, so it's out there).
Well, it's present as long as I can remember, but an sanity check
wouldn't hurt there.
> 8) perms on the new files?
Ok.
> 9) general code comments; 'if s != ""', use 'if s:'. Catch the
> exceptions for check mode, don't let vdbkeyhandler nuke world file
> checking due to a potential exception. Right now, your
Re: [gentoo-portage-dev] making aux_get more usable for vardbapi
On Mon, Jan 23, 2006 at 07:44:44PM +0100, Marius Mauch wrote:
> On Mon, 23 Jan 2006 03:47:11 -0800
> Brian Harring <[EMAIL PROTECTED]> wrote:
> > On Mon, Jan 23, 2006 at 11:16:03AM +0100, Marius Mauch wrote:
> > > On Wed, 11 Jan 2006 12:39:03 -0800
> > > Brian Harring <[EMAIL PROTECTED]> wrote:
> > >
> > > > 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...
> > >
> > > Not really an issue in this case. First the code bails out if more
> > > than one match is found, so unless the metadata assignment is NOT
> > > found by it we don't get the wrong info.
> > > Also a mismatch in this special is so
> > > extremely unlikely that honestly I don't really care about it,
> > > especially as this is a one time conversion (might be different if
> > > I'd have added the on the fly extraction).
> >
> > Re-read that statement. It's a one time conversion- meaning we
> > better get it right the first time, else the user's data is
> > effectively corrupted. Forcing a full regen from the saved
> > environment is not a solution for fixing past corruptions either.
> >
> > If it were on the fly extraction, I wouldn't care quite as much- but
> > the fact this is an untracked change to the users data means we *do*
> > need to cover corner cases.
>
> Can't follow your thinking here. As said, the code won't corrupt any
> data, at worst it will tell the user that it couldn't extract some keys
> (and even that only if there would be such a stupid case which itself
> has a chance of like 10^-10 or so, or can you name a single case?).
Yeah, any extension of your code to pick up EAPI is going to false
positive on somewhere around a quarter of my vdb nodes- I use a
debug function from my bashrc for prefix testing (holdover from eapi
testing days). Why? Because the eapi var didn't exist (thus no env
assignment), the only possible match is in the middle of a here op-
debug_dump() {
...
echo <<&2
EAPI="${EAPI-unset}"
PF="$PF"
CATEGORY="$CATEGORY"
HERE
...
}
Setting EAPI to unset strikes me as corruption here, because now
portage will *never* do anything with that vdb node- the eapi differs
from what it supports (it's been set to effectively a random value),
thus I have to fix the vdb entry myself if I ever want to get rid of
it.
Guessing the response on that one is "well, you're using the bashrc",
and yes, I am- the vdb code should be *robust*, not choking on a users
debug code.
> So what package contains filter-env then?
Portage- been in cvs/svn for over a year now :)
> > Aside from that, if the code is in debate (as this is), I really
> > don't think it should get slid into svn 2 weeks later effectively
> > unchanged- didn't write that original email just for the hell of it :)
>
> As said, I disagree with your assessment of the situation. If you can
> name a single case where the code "breaks" or filter-env hits the tree
> I might reconsider, but not before.
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).
Issues with the code.
1) Scans for metadata that didn't exist at the time of the ebuild's
installation, only possible match is unintended. Not good.
2) your code is breaking upon *all* newlines, regardless if it's
in the middle of a variable assignment. Yes, bash does use $'' for
assignment, but you're relying (hoping really) that the variable has
been filtered by python portage and the ebuild defined var is stomped.
This is a bad idea- description comes to mind. Your code seems to be
aware of this possibility also, since it's doing rather loose quote
filtering.
3) Stop using regex all over the place. split/join is a helluva lot
faster, and collapses that nasty regex that attempts to remove
whitespace down to two lines (a one time translate, and the split/join
to kill whitespace).
4) Code specifically tries to find, and remove variable chars-
this is *really* the wrong thing to do. If you're trying to work
around catching a var reference, either your parsing screwed up, or
you're mangling a DESCRIPTION value that you shouldn't be hosing.
5) hardcoded vdb.
6) Non root aware VDB.
7) Only is aware of environment.bz2- older portage versions differed
in this afaik (I *do* know PORT_ENV_FILE overloading for ebd I had to
address this case already, so it's out there).
8) perms on the new files?
9) general code comments; 'if s != ""', use 'if s:'. Catch the
excep
Re: [gentoo-portage-dev] making aux_get more usable for vardbapi
On Mon, 23 Jan 2006 03:47:11 -0800 Brian Harring <[EMAIL PROTECTED]> wrote: > On Mon, Jan 23, 2006 at 11:16:03AM +0100, Marius Mauch wrote: > > On Wed, 11 Jan 2006 12:39:03 -0800 > > Brian Harring <[EMAIL PROTECTED]> wrote: > > > > > 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... > > > > Not really an issue in this case. First the code bails out if more > > than one match is found, so unless the metadata assignment is NOT > > found by it we don't get the wrong info. > > Also a mismatch in this special is so > > extremely unlikely that honestly I don't really care about it, > > especially as this is a one time conversion (might be different if > > I'd have added the on the fly extraction). > > Re-read that statement. It's a one time conversion- meaning we > better get it right the first time, else the user's data is > effectively corrupted. Forcing a full regen from the saved > environment is not a solution for fixing past corruptions either. > > If it were on the fly extraction, I wouldn't care quite as much- but > the fact this is an untracked change to the users data means we *do* > need to cover corner cases. Can't follow your thinking here. As said, the code won't corrupt any data, at worst it will tell the user that it couldn't extract some keys (and even that only if there would be such a stupid case which itself has a chance of like 10^-10 or so, or can you name a single case?). Also with on the fly extraction (note: not talking about on the fly conversion here) it would be a more serious problem as it woldn't be time limited. > I know you want this in, but it has to be done *right* covering all > known corner cases for it- I already wrote the tool that handles the > corner cases properly, use it, don't adhoc a solution that > re-introduces the potential gaps. So what package contains filter-env then? > Aside from that, if the code is in debate (as this is), I really > don't think it should get slid into svn 2 weeks later effectively > unchanged- didn't write that original email just for the hell of it :) As said, I disagree with your assessment of the situation. If you can name a single case where the code "breaks" or filter-env hits the tree I might reconsider, but not before. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-portage-dev] making aux_get more usable for vardbapi
On Mon, Jan 23, 2006 at 11:16:03AM +0100, Marius Mauch wrote: > On Wed, 11 Jan 2006 12:39:03 -0800 > Brian Harring <[EMAIL PROTECTED]> wrote: > > > 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... > > Not really an issue in this case. First the code bails out if more than > one match is found, so unless the metadata assignment is NOT found by > it we don't get the wrong info. > Also a mismatch in this special is so > extremely unlikely that honestly I don't really care about it, > especially as this is a one time conversion (might be different if I'd > have added the on the fly extraction). Re-read that statement. It's a one time conversion- meaning we better get it right the first time, else the user's data is effectively corrupted. Forcing a full regen from the saved environment is not a solution for fixing past corruptions either. If it were on the fly extraction, I wouldn't care quite as much- but the fact this is an untracked change to the users data means we *do* need to cover corner cases. I know you want this in, but it has to be done *right* covering all known corner cases for it- I already wrote the tool that handles the corner cases properly, use it, don't adhoc a solution that re-introduces the potential gaps. If we're not going to do it right, we really shouldn't do it when it comes to upgrades of the vdb. Aside from that, if the code is in debate (as this is), I really don't think it should get slid into svn 2 weeks later effectively unchanged- didn't write that original email just for the hell of it :) ~harring pgp8DlaOCY2aR.pgp Description: PGP signature
Re: [gentoo-portage-dev] making aux_get more usable for vardbapi
On Wed, 11 Jan 2006 12:39:03 -0800 Brian Harring <[EMAIL PROTECTED]> wrote: > 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... Not really an issue in this case. First the code bails out if more than one match is found, so unless the metadata assignment is NOT found by it we don't get the wrong info. Also a mismatch in this special is so extremely unlikely that honestly I don't really care about it, especially as this is a one time conversion (might be different if I'd have added the on the fly extraction). All together makes this pretty much a hypothetical issue with no practical relevance. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-portage-dev] making aux_get more usable for vardbapi
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 pgpPpYlagEdYF.pgp Description: PGP signature
[gentoo-portage-dev] making aux_get more usable for vardbapi
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?
Marius
--
Public Key at http://www.genone.de/info/gpg-key.pub
In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
--- /home/gentoo/svn/portage/main/trunk/bin/ebuild.sh 2006-01-08 04:30:16.0 +0100
+++ /usr/lib/portage/bin/ebuild.sh 2006-01-10 18:27:15.0 +0100
@@ -914,7 +914,8 @@
for f in ASFLAGS CATEGORY CBUILD CC CFLAGS CHOST CTARGET CXX \
CXXFLAGS DEPEND EXTRA_ECONF EXTRA_EINSTALL EXTRA_MAKE \
FEATURES INHERITED IUSE LDFLAGS LIBCFLAGS LIBCXXFLAGS \
- LICENSE PDEPEND PF PKGUSE PROVIDE RDEPEND RESTRICT SLOT; do
+ LICENSE PDEPEND PF PKGUSE PROVIDE RDEPEND RESTRICT SLOT \
+ KEYWORDS HOMEPAGE SRC_URI DESCRIPTION; do
[ -n "${!f}" ] && echo $(echo "${!f}" | tr '\n,\r,\t' ' , , ' | sed s/' \+'/' '/g) > ${f}
done
echo "${USE}" > USE
--- /home/gentoo/svn/portage/main/trunk/pym/portage.py 2006-01-08 04:30:11.0 +0100
+++ /usr/lib/portage/pym/portage.py 2006-01-10 18:28:00.0 +0100
@@ -4501,17 +4477,32 @@
def aux_get(self, mycpv, wants):
global auxdbkeys
results = []
+ envlines = None
for x in wants:
- myfn = self.root+VDB_PATH+"/"+str(mycpv)+"/"+str(x)
- if os.access(myfn,os.R_OK):
-myf = open(myfn, "r")
+ mydir = self.root+VDB_PATH+"/"+str(mycpv)+"/"
+ if os.access(mydir+str(x),os.R_OK):
+myf = open(mydir+str(x), "r")
myd = myf.read()
myf.close()
-myd = re.sub("[\n\r\t]+"," ",myd)
-myd = re.sub(" +"," ",myd)
-myd = string.strip(myd)
+ # Fallback to searching environment.bz2 if no key-specific file exists
+ elif os.access(mydir+"environment.bz2", os.R_OK):
+if not envlines:
+ env = os.popen("bzip2 -dcq "+mydir+"environment.bz2", "r")
+ envlines = env.read().split("\n")
+ env.close()
+myd = [l for l in envlines if l.strip("\"\'").startswith(x+"=")]
+if len(myd) > 1:
+ raise portage_exception.CorruptionError("multiple matches for "+x+" found in "+mydir+"environment.bz2")
+elif len(myd) == 0:
+ myd = ""
+else:
+ myd = myd[0].split("=",1)[1]
+ myd = myd.lstrip("$").strip("\'\"")
+ myd = re.sub("([nrt])+", " ", myd)
else:
myd = ""
+ myd = re.sub("[\n\r\t]+"," ",myd)
+ myd = re.sub(" +"," ",myd)
+ myd = string.strip(myd)
results.append(myd)
if "EAPI" in wants:
idx = wants.index("EAPI")
--- /home/gentoo/svn/portage/main/trunk/bin/emaint 2006-01-08 04:30:16.0 +0100
+++ /usr/lib/portage/bin/emaint 2006-01-10 19:29:20.0 +0100
@@ -4,7 +4,7 @@
from copy import copy
from optparse import OptionParser, OptionValueError
-
+import re
import os, portage, portage_const
class WorldHandler(object):
@@ -44,8 +44,65 @@
errors.append(portage_const.WORLD_FILE + " could not be opened for writing")
return errors
+class VdbKeyHandler(object):
+ def name():
+ return "vdbkeys"
+ name = staticmethod(name)
+
+ def __init__(self):
+ self.list = portage.db["/"]["vartree"].dbapi.cpv_all()
+ self.missing = []
+ self.keys = ["HOMEPAGE", "SRC_URI", "KEYWORDS", "DESCRIPTION"]
+
+ for p in self.list:
+ mydir = "/var/db/pkg/"+p
+ ismissing = True
+ for k in self.keys:
+if os.path.exists(mydir+"/"+k):
+ ismissing = False
+ break
+ if ismissing:
+self.missing.append(p)
+
+ def check(self):
+ return ["%s has missing keys" % x for x in self.missing]
+
+ def fix(self):
+
+ errors = []
+
+ for p in self.missing:
+ mydir = "/var/db/pkg/"+p
+ if not os.access(mydir+"/environment.bz2", os.R_OK):
+errors.append("Can't access %s" % (mydir+"/environment.bz2"))
+ elif not os.access(mydir, os.W_OK):
+errors.append("Can't create files in %s" % mydir)
+ else:
+env = os.popen("bzip2 -dcq "+mydir+"/environment.bz2
