Re: [gentoo-portage-dev] portage and porthole
On Thu, Nov 10, 2005 at 09:29:22PM -0800, Brian wrote:
> On Thu, 2005-10-11 at 20:51 -0600, Brian Harring wrote:
> > On Thu, Nov 10, 2005 at 06:42:54PM -0800, Brian wrote:
> > > Just a quick question. With all the changes I see in this list. Is
> > > there anything coming (that you know of) that will break porthole's use
> > > of portage.
> > Long term? I'm unfortunately looking at breaking pretty much all api
> > access portage wise, for 3.0.
>
> I knew that one. From what I have gathered so far I believe 3.0 is
> getting the long awaited public API. Is that correct? If so I'll have
> to start paying more attention to it and setup a test box to start
> changing our portagelib.py to use it. (I can't afford to trash my main
> box, I have business stuff on it.) Just let me know when it's time for
> testing. :)
Actually... it's stand alone. I'm working on it alongside stable.
It lives in it's own namespace python wise (rather then what stable
does), so it doesn't interfere with anything :)
Regarding API; yah, something will be there- I haven't thought about a
true high level API for it yet, but at least the internal stuff is
pretty straightforward- what it should be one things are finished up-
domain=portage.config.load_config().default_domain
from portage.package.atom import atom
p = max(domain.repos.match(atom("dev-util/diffball"))) # get the max available
version
b = p.build() # get a build op
b.finalize() # build the sucker
domain.vdbs.add(b)
Is basically what it will be; the nasty stuff required for stable
won't be there, since this is actuall OOP rather then procedural
spaghetti.
May, or may not layer an API over it, although that's something down
the line. Right now working on the v.add chunk.
> > Short term? Unless you're doing questionable stuff like bypassing the
> > cache layer and accessing the files on disk... nope, shouldn't hork
> > anything.
> >
> > ~harring
>
> mostly just lookup stuff, get defaults, status, package info, etc.. All
> emerges are done properly through a terminal and normal command line
> calls.
Yah, nothing that's been talked about should affect querying
interfaces.
~harring
pgpP1xojMdLXM.pgp
Description: PGP signature
Re: [gentoo-portage-dev] portage and porthole
On Thu, 2005-10-11 at 20:51 -0600, Brian Harring wrote: > On Thu, Nov 10, 2005 at 06:42:54PM -0800, Brian wrote: > > Just a quick question. With all the changes I see in this list. Is > > there anything coming (that you know of) that will break porthole's use > > of portage. > Long term? I'm unfortunately looking at breaking pretty much all api > access portage wise, for 3.0. I knew that one. From what I have gathered so far I believe 3.0 is getting the long awaited public API. Is that correct? If so I'll have to start paying more attention to it and setup a test box to start changing our portagelib.py to use it. (I can't afford to trash my main box, I have business stuff on it.) Just let me know when it's time for testing. :) > > Short term? Unless you're doing questionable stuff like bypassing the > cache layer and accessing the files on disk... nope, shouldn't hork > anything. > > ~harring mostly just lookup stuff, get defaults, status, package info, etc.. All emerges are done properly through a terminal and normal command line calls. Thanks... -- Brian <[EMAIL PROTECTED]> -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] portage and porthole
On Thu, Nov 10, 2005 at 06:42:54PM -0800, Brian wrote: > Just a quick question. With all the changes I see in this list. Is > there anything coming (that you know of) that will break porthole's use > of portage. Long term? I'm unfortunately looking at breaking pretty much all api access portage wise, for 3.0. Short term? Unless you're doing questionable stuff like bypassing the cache layer and accessing the files on disk... nope, shouldn't hork anything. ~harring pgpxz1Stqo4LM.pgp Description: PGP signature
[gentoo-portage-dev] portage and porthole
Just a quick question. With all the changes I see in this list. Is there anything coming (that you know of) that will break porthole's use of portage. So far I have not experienced any real difficulties. The only hick-up I had was reloading portage after updating to _rc7. Portage failed to find one of it's modules. Restarting porthole, it was fine. Since this version of porthole is so stable I was going to suggest that it is ready for a stable arch keyword. Of course that will depend on your answer to the above question. cheers :) -- Brian <[EMAIL PROTECTED]> -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Portage rating in O'Reilly book
On Thu, 2005-10-11 at 11:09 -0800, Donnie Berkholz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I don't know whether all of you read my blog, but I wanted to make sure > you saw this: > http://www.livejournal.com/users/spyderous/60809.html?thread=89737#t89737. > It's a reply from the author of a book on why he rated our package > management at a 4 instead of a 5, and it gives some good ideas on where > users feel things could improve. > > Feel free to ignore the binary packages bit, as that's more of a Gentoo > philosophical issue. > > Thanks, > Donnie GUI wise, porthole-0.5.0 is much improved over previous versions. It runs very smooth now with hick-ups a rarity. :) All We are waiting for now is some last minute translation updates for it's next release. With all the changes and bug fixes I see in my mail these days, by this time next year things will have improved a whole bunch. Keep up the good work :) -- Brian <[EMAIL PROTECTED]> -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] Portage rating in O'Reilly book
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I don't know whether all of you read my blog, but I wanted to make sure you saw this: http://www.livejournal.com/users/spyderous/60809.html?thread=89737#t89737. It's a reply from the author of a book on why he rated our package management at a 4 instead of a 5, and it gives some good ideas on where users feel things could improve. Feel free to ignore the binary packages bit, as that's more of a Gentoo philosophical issue. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDc5riXVaO67S1rtsRAkWBAJ9QkjDsltO24UrGW9oF2WKNkAL1cACfUDRY OcCUgni8pLJ9CMxN/Bx1fC0= =wOGZ -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] Depgraph reworking
Going through some of the older bugs, I've started reworking emerge's depgraph
code to try and work some of them out. I've attached where I'm at (--pretend
works) but am wondering what we should do about big new patches like this. My
first instinct would be to say 2.0.55 or 2.1.0 (whatever happens there). What
do people think?
The patch, by the way, is currently in the order of +725,-946. Most of the
additions come from copying the graph_display class from 2.1-experimental.
The reworking of depgraph so far on its own has turned 467 lines into 207;
that's with adding support for utiziling package info from the /var/db/pkg!
Beyond fixing some of the older bugs, the goal is also to make it all a little
easier to understand. Let me know if I'm failing there. ;)
P.S. Nope, I'm not going to touch circular deps or anything like that here. :P
P.P.S. While I haven't got everything working yet, times have gone from 1.95
to 1.60 seconds on my box here. :)
--
Jason Stubbs
Index: pym/portage.py
===
--- pym/portage.py (revision 2264)
+++ pym/portage.py (working copy)
@@ -382,29 +382,22 @@
self.okeys=[]
def addnode(self,mykey,myparent):
- if not self.dict.has_key(mykey):
+ if mykey not in self.dict:
self.okeys.append(mykey)
- if myparent==None:
-self.dict[mykey]=[0,[]]
- else:
-self.dict[mykey]=[0,[myparent]]
-self.dict[myparent][0]=self.dict[myparent][0]+1
- return
- if myparent and (not myparent in self.dict[mykey][1]):
+ self.dict[mykey] = [[], []]
+ if myparent and myparent not in self.dict[mykey][1]:
self.dict[mykey][1].append(myparent)
- self.dict[myparent][0]=self.dict[myparent][0]+1
+ self.dict[myparent][0].append(mykey)
def delnode(self,mykey):
- if not self.dict.has_key(mykey):
- return
+ if mykey not in self.dict:
+ raise KeyError,mykey
for x in self.dict[mykey][1]:
- self.dict[x][0]=self.dict[x][0]-1
+ self.dict[x][0].remove(mykey)
+ for x in self.dict[mykey][0]:
+ self.dict[x][1].remove(mykey)
del self.dict[mykey]
- while 1:
- try:
-self.okeys.remove(mykey)
- except ValueError:
-break
+ self.okeys.remove(mykey)
def allnodes(self):
"returns all nodes in the dictionary"
@@ -413,34 +406,10 @@
def firstzero(self):
"returns first node with zero references, or NULL if no such node exists"
for x in self.okeys:
- if self.dict[x][0]==0:
+ if not self.dict[x][0]:
return x
return None
- def depth(self, mykey):
- depth=0
- while (self.dict[mykey][1]):
- depth=depth+1
- mykey=self.dict[mykey][1][0]
- return depth
-
- def allzeros(self):
- "returns all nodes with zero references, or NULL if no such node exists"
- zerolist = []
- for x in self.dict.keys():
- mys = string.split(x)
- if mys[0] != "blocks" and self.dict[x][0]==0:
-zerolist.append(x)
- return zerolist
-
- def hasallzeros(self):
- "returns 0/1, Are all nodes zeros? 1 : 0"
- zerolist = []
- for x in self.dict.keys():
- if self.dict[x][0]!=0:
-return 0
- return 1
-
def empty(self):
if len(self.dict)==0:
return 1
@@ -452,8 +421,8 @@
def copy(self):
mygraph=digraph()
for x in self.dict.keys():
- mygraph.dict[x]=self.dict[x][:]
- mygraph.okeys=self.okeys[:]
+ mygraph.dict[x] = [self.dict[x][0][:], self.dict[x][1][:]]
+ mygraph.okeys=self.okeys[:]
return mygraph
# valid end of version components; integers specify offset from release version
Index: bin/emerge
===
--- bin/emerge (revision 2266)
+++ bin/emerge (working copy)
@@ -304,9 +304,11 @@
"""
-if (myaction in ["world", "system"]) and myfiles:
- print "emerge: please specify a package class (\"world\" or \"system\") or individual packages, but not both."
- sys.exit(1)
+if myaction:
+ myaction = [myaction]
+ myaction.extend(myfiles)
+else:
+ myaction = myfiles
for x in myfiles:
ext = os.path.splitext(x)[1]
@@ -894,8 +896,7 @@
portage.writemsg(red("\a!!! ARCH is not set... Are you missing the /etc/make.profile symlink?\n"))
portage.writemsg(red("\a!!! Is the symlink correct? Is your portage tree complete?\n\n"))
sys.exit(9)
- self.applied_useflags = {}
-
+ self.useflags = {}
self.missingbins=[]
self.myaction=myaction
self.digraph=portage.digraph()
@@ -912,857 +913,201 @@
for pkg in portage.db[portage.root]["vartree"].getallcpv():
self.mydbapi[portage.root].cpv_inject(pkg)
+ self.default_trees = []
+ if "selective" in myparams:
+ self.default_trees.append("vartree")
if "--usepkg" in myopts:
+ self.default_trees.append("bintree")
+ if "--usepkgonly" not in myopts:
+ self.default_trees.append("porttree")
+
+ if "--usepkg" in myopts:
portage.db["/"]["bintree"].populate(("--getbinpkg" in myopts), ("--getbinpkgonly" in myopts))
- def create(self,mybigkey,myparent=None,addme=1,myuse=None):
- """creates the actual digraph of packages to merge. return 1
