1 |
On Mon, 2004-10-18 at 22:53 +0900, Jason Stubbs wrote: |
2 |
|
3 |
> I'm more interested in what you are already using and more importantly why. |
4 |
> Whatever the API ends up being, it'll probably resemble portage's current API |
5 |
> very little. |
6 |
> |
7 |
> I'll try to ascertain the why's from the what's that you've listed. Let me |
8 |
> know if I get any wrong. |
9 |
> |
10 |
> > portage.grabfile():: used for obtaining [keywords.desc, use.desc, |
11 |
> > use.local.desc] |
12 |
> |
13 |
> Descriptions of USE flags. (I don't know what keywords.desc is.) |
14 |
> |
15 |
|
16 |
keywords.desc does not exist on my system: func() call = |
17 |
portage.grabfile('/usr/portage/profiles/keywords.desc') |
18 |
|
19 |
It seems to be a depricated function in porthole, the output it stored |
20 |
if found was not used anywhere. I am deleting it. |
21 |
|
22 |
> > portage.config(clone=portage.settings).environ()[var] :: where var = 1 of |
23 |
> > ['PORTDIR_OVERLAY','PORTDIR', "USE"] |
24 |
> |
25 |
> The current USE settings. I'm don't see why PORTDIR or PORTDIR_OVERLAY is |
26 |
> needed. |
27 |
|
28 |
Porthole searches the directories for ebuilds, etc.. Better to use the |
29 |
correct directories, so get the correct directories. I believe Dan was |
30 |
using portage rather than creating new code to scan thru /etc/make.conf |
31 |
as well as the globals & defaults. |
32 |
|
33 |
> |
34 |
> > portage.auxdbkeys |
35 |
> |
36 |
> I'm not sure what's required here either. |
37 |
|
38 |
I'll look into it further. |
39 |
|
40 |
|
41 |
> |
42 |
> > """Extract installed versions from full name.""" |
43 |
> > return portage.db['/']['vartree'].dep_match(full_name) |
44 |
> |
45 |
> Querying the installed package database. |
46 |
> |
47 |
> > portage.db['/']['porttree'].getallnodes() |
48 |
> |
49 |
> Querying the ebuild package database. |
50 |
> |
51 |
> > portage.db['/']['vartree'].getallnodes() |
52 |
> |
53 |
> As above. |
54 |
> |
55 |
> > portage.catpkgsplit(ebuild) |
56 |
> |
57 |
> Not sure why this is needed. |
58 |
|
59 |
looks like = convienence, why re-invent the code to split the |
60 |
cat/package-version. |
61 |
|
62 |
> |
63 |
> > portage.portdb.aux_get(ebuild, [property])[0] |
64 |
> |
65 |
> Querying individual packages. |
66 |
> |
67 |
> > portage.best(versions) |
68 |
|
69 |
for finding picking specific ebuild properties to display, etc. |
70 |
|
71 |
|
72 |
> |
73 |
> > # showing complete porthole function for (possibly) more clarity |
74 |
> > def get_properties(ebuild): |
75 |
> > """Get all ebuild variables in one chunk.""" |
76 |
> > return Properties(dict(zip(keys, |
77 |
> > portage.portdb.aux_get(ebuild, |
78 |
> > portage.auxdbkeys)))) |
79 |
> > |
80 |
> > |
81 |
> > def get_versions(self, include_masked = True): |
82 |
> > """Returns all versions of the available ebuild""" |
83 |
> > # Note: this slow, especially when include_masked is false |
84 |
> > criterion = include_masked and 'match-all' or 'match-visible' |
85 |
> > return portage.portdb.xmatch(criterion, self.full_name) |
86 |
> |
87 |
> I think these are both covered above. |
88 |
> |
89 |
> > Wish list: |
90 |
> > |
91 |
> > Portages version comparison/handling code from bug: |
92 |
> > http://bugs.gentoo.org/show_bug.cgi?id=37406 was would be implemented soon. |
93 |
> > I see browsing thru 2.0.51_rc9 that it is not yet implemented. If it is |
94 |
> > being implemented Porthole should use the following from portage's code: |
95 |
> > |
96 |
> > ver_regexp = |
97 |
> > re.compile("^(cvs-)?(\\d+)((\\.\\d+)*)([a-zA-Z]?)((_(pre|p|beta|alpha|rc)\\ |
98 |
> >d*)*)(-r(\\d+))?$") suffix_regexp = |
99 |
> > re.compile("^(alpha|beta|rc|pre|p)(\\d*)$") |
100 |
> > # modified portage comparison suffix values for sorting in desired |
101 |
> > precedence suffix_value = {"alpha": '0', "beta": '1', "pre": '2', "rc": |
102 |
> > '3', "p": '4'} |
103 |
> |
104 |
> This is covered above with version comparison. |
105 |
> |
106 |
|
107 |
No it isn't. Portage's vercmp() is used to return the best ebuild of |
108 |
two supplied. Porthole needs to sort a list of available ebuilds to |
109 |
proper order. I based that code from Marius's changed code for vercmp() |
110 |
so that porthole could display the ebuild version list in the correct |
111 |
order. |
112 |
|
113 |
|
114 |
> > That would allow porthole's modified version of that code to follow any |
115 |
> > changes in portage's values. |
116 |
> |
117 |
> I strongly recommend against doing any of this sort of stuff manually. I know |
118 |
> that there isn't really much choice at the moment, but that's exactly what |
119 |
> we're trying to get away from. |
120 |
|
121 |
To use portage's vercmp() I would have to write a python bubble sort to |
122 |
sort a list of ebuild versions. What I did was use Marius's code and |
123 |
modified it to pad the version string parts to 3 digits then used |
124 |
python's builtin list.sort(). |
125 |
|
126 |
> |
127 |
> I believe porthole also makes a lot of use of emerge. If possible, please let |
128 |
> me know what options it is called with and what output is parsed. |
129 |
> |
130 |
Porthole can currently send any emerge option by use of the advanced |
131 |
emerge dialog for the most common advanced options or the run_custom |
132 |
dialog which inputs any command to send to the terminal. I have run ls, |
133 |
python-updater and a few others as a test. |
134 |
|
135 |
Due to porthole-terminal not being interactive commands such as "emerge |
136 |
-a" will hang waiting for input that it can not receive. |
137 |
|
138 |
|
139 |
We currently filter out any warning, caution, summary info including any |
140 |
">>>" statements, einfo statements, errors. For a complete list look |
141 |
in the configuration.xml file attached. |
142 |
|
143 |
I would like to change the terminal to use the vte gtk terminal widget |
144 |
which could allow it to be a full function terminal with the message |
145 |
filtering, su & chroot ability. I did have a somewhat functional |
146 |
version I tested but the python interface was incomplete and is not |
147 |
really developed. I would need to re-code the terminal in c. In case |
148 |
you didn't know vte is gnome-terminals major workings that was split |
149 |
into the main virtual terminal widget and the gnome-terminal |
150 |
enhancements. |
151 |
|
152 |
|
153 |
-- |
154 |
Brian <dol-sen@×××××.net> |