| 1 |
Thans for your answer, I'll investigate that stuff. |
| 2 |
But currently more important for me is, where else in the web I can find |
| 3 |
informations about the updates in the portage tree. |
| 4 |
As I said, I can parse packages.gentoo.org, but it contains much overhead. |
| 5 |
ViewPortageX currently is used at least on 500 systems, but there come more |
| 6 |
and more. |
| 7 |
It would put some load on the server when I let the theme fetch so many |
| 8 |
information from packages.gentoo.org as I need it to do. |
| 9 |
|
| 10 |
So, perhaps somebody knows how I can do this more efficiently. |
| 11 |
|
| 12 |
> Perhaps you may find portholes code easier to find out how to obtain |
| 13 |
> info from portage. The portagelib.py file is where all portage |
| 14 |
> interaction takes place. Since the devs know about what it uses already |
| 15 |
> it is probably the safest code taps from portage to use. You should be |
| 16 |
> able to get all the info you need from those examples. |
| 17 |
> |
| 18 |
> Also you may want to keep track of pkgcore_lib.py. It is the next |
| 19 |
> generation portage code that will be coming our way. I have only just |
| 20 |
> started integrating it for porthole (my first commit of it last night). |
| 21 |
> Many things will change by the time the code is ready for general use, |
| 22 |
> but will give you an idea of how to plan ahead. The tree structure is |
| 23 |
> quite a bit different than current portage. I know I will need to re-do |
| 24 |
> a bunch of porthole's code to be optimized for the new structure. Also |
| 25 |
> it should be faster. So far, just building all the available packages |
| 26 |
> from the local tree as well as all installed packages is about 1 sec. |
| 27 |
> faster on my machine, probably better again when it's ironed out. If |
| 28 |
> there is something lacking in it's API, Brian Harring wants to know. |
| 29 |
> |
| 30 |
> -- |
| 31 |
> Brian <dol-sen@×××××.net> |
| 32 |
-- |
| 33 |
gentoo-portage-dev@g.o mailing list |
Archives