1 |
I did think about it now and it seems to me that probably it would be |
2 |
much faster if esearch is not just another package, but part of |
3 |
portage. |
4 |
|
5 |
I mean -- functions of portage, which query db, should use esearch |
6 |
index wherever they need information, which exists in that index. |
7 |
|
8 |
As much as i can understand, /var/cache/edb/ contains esearch database |
9 |
in many files and esearchdb.py is search index as python script. |
10 |
|
11 |
I think that SQL functions for searching and other things are maybe |
12 |
not much faster than py (as py seems to be fast enough, at least if |
13 |
there are more important things to do), but simpler to use. Therefore |
14 |
i think that rewriting the whole thing with SQL support may be still |
15 |
better. |
16 |
|
17 |
I will make it clear for me, what those emerge db functions do and |
18 |
still try to do something, what connects them to SQL. |
19 |
|
20 |
Anyway, i am still interested, is there some code or other |
21 |
documentation about how portage works, especially how it keeps it's |
22 |
data? |
23 |
|
24 |
2006/3/14, tvali <qtvali@×××××.com>: |
25 |
> Another question now is about sync. |
26 |
> |
27 |
> I did read somewhere, that this is not good user behavior to sync more |
28 |
> than once per day. I understand that as if this is a huge download |
29 |
> even if there is nothing changed. |
30 |
> |
31 |
> Isnt it nice idea to have this database just optimized? |
32 |
> |
33 |
> I mean (assuming portage using SQL now) -- that would be really simple |
34 |
> to log every change in portage tree as series of SQL queries, which |
35 |
> would reproduce this change. |
36 |
> |
37 |
> There could be table, which contains two fields -- Id and query (for |
38 |
> example -- in reality, it could be a bit more complex for whatever |
39 |
> reason; datetime, for example -- or filename and it's content to |
40 |
> support current portage filetree). If i do emerge --sync, then one |
41 |
> query could be done, SELECT query FROM updates WHERE Id > |
42 |
> LastDownloadedUpdateId ORDER BY Id, then run all queries. |
43 |
> |
44 |
> I guess that in such case, portage --sync would be faster and less |
45 |
> server-expensive. I dont know about this cache it builds, but i |
46 |
> suppose that this could be made faster, too :) |
47 |
> |
48 |
> Ok, i will work now a bit, but i hope you have time to explain to me, |
49 |
> if something i tell here is stupid or not-so-important for whatever |
50 |
> reason. |
51 |
> |
52 |
> 2006/3/14, tvali <qtvali@×××××.com>: |
53 |
> > Thank you much! |
54 |
> > |
55 |
> > This is what i meant about searching :) Would it be now good to mix |
56 |
> > this esearch code with emerge, then adding fields to db and making |
57 |
> > emerge treebuilding fast, too? Or is there some utility to emerge, |
58 |
> > which does all that? |
59 |
> > |
60 |
> > 2006/3/14, Devon Miller <devon.c.miller@×××××.com>: |
61 |
> > > Try "emerge esearch". Replace "emerge --sync" with "esync", "emerge -s" with |
62 |
> > > "esearch", and "emerge -S" with "esearch -S". |
63 |
> > > After running "emerge --update ...", run "eupdatedb". |
64 |
> > > |
65 |
> > > As for dependency tree: "emerge --pretend --tree world" |
66 |
> > > Or, to also check additional dependencies: "emerge --deep --pretend --tree |
67 |
> > > world" |
68 |
> > > And, if you want to see how *everything* relates: "emerge --deep --emptytree |
69 |
> > > --pretend --tree" |
70 |
> > > |
71 |
> > > dcm |
72 |
> > > |
73 |
> > > |
74 |
> > > |
75 |
> > > On 3/14/06, tvali <qtvali@×××××.com> wrote: |
76 |
> > > > |
77 |
> > > > Another place, where it would be good, is that it could interact well with |
78 |
> > > GUI and it's Apply button. |
79 |
> > > > |
80 |
> > > > Another thing, what would be imho improved, is the speed of following |
81 |
> > > functions: |
82 |
> > > > * emerge -s, emerge -S |
83 |
> > > > They should be cached somehow. |
84 |
> > > > |
85 |
> > > > Also, i think that when speaking about *speed* of portage, which is imho |
86 |
> > > notably slow right now (speed of searching, building trees and so on), |
87 |
> > > sql-support should be considered. In /usr/portage/, i see many folders and |
88 |
> > > files, which tend to contain one or two words, lists of hashes and so on. |
89 |
> > > Actually i see relational database there. With many caches and other |
90 |
> > > optimizations it could be tuned fast, but having SQL doing all that, it |
91 |
> > > would be achieved very simply (maybe it would be a jump to have all linux |
92 |
> > > configurations in one SQL "filesystem"? ...ok, just fantasy:)) |
93 |
> > > > |
94 |
> > > > There are several small and simple SQL databases. With such tool, big |
95 |
> > > parts of portage become unnessecary, but it's speed will become much faster. |
96 |
> > > This should be optional if one uses some tiny sql, mysql or big clustered |
97 |
> > > sql with nas and load-balancer, but by default some tiny version of SQL |
98 |
> > > should be built. |
99 |
> > > > |
100 |
> > > > Also, i currently dont see a possibility to see dependency tree of |
101 |
> > > installed package. |
102 |
> > > > |
103 |
> > > > |
104 |
> > > > |
105 |
> > > > 2006/3/14, tvali < qtvali@×××××.com>: |
106 |
> > > > > I did think about some priorities too, so that it could be perfect for |
107 |
> > > me. |
108 |
> > > > > |
109 |
> > > > > It should be possible to add package with a priority. I will give you an |
110 |
> > > use case and explanation how i would use portage. |
111 |
> > > > > |
112 |
> > > > > emerge --justadd kdebase-meta kicker --priority 10 |
113 |
> > > > > emerge --justadd kdenetwork-meta kdeutils-meta kdeadmin-meta --priority |
114 |
> > > 9 |
115 |
> > > > > emerge --justadd kdeedu-meta kdetoys-meta kdegames-meta kdeartwork-meta |
116 |
> > > --priority 1 |
117 |
> > > > > emerge --justadd koffice-meta kdegraphics-meta kdemultimedia-meta |
118 |
> > > --priority 5 |
119 |
> > > > > emerge --justadd kdewebdev-meta kdevelop htmltidy kompare cervisia |
120 |
> > > --priority 7 |
121 |
> > > > > emerge --justadd kdepim-meta --priority 3 |
122 |
> > > > > emerge --justadd kdeaddons-meta kde-meta --priority 20 |
123 |
> > > > > emerge --changepriority kdeaddons-meta kde-meta --priority 0 |
124 |
> > > > > |
125 |
> > > > > Now, when i run emerge --update, it should: |
126 |
> > > > > |
127 |
> > > > > * Sort packages in such order that packages with highest priority would |
128 |
> > > be installed as soon as possible |
129 |
> > > > > * Start installing |
130 |
> > > > > * If something goes wrong, then skip this package and all, which depend |
131 |
> > > on it. This should be optional, if those, which dont depend on it, but are |
132 |
> > > needed by same package, will stay in their positions (go to end of same |
133 |
> > > priority packages) or go to end. |
134 |
> > > > > |
135 |
> > > > > When i need to use my computer and need much resources, i will press |
136 |
> > > ctrl-c, use it, then start (continue) emerge --update. |
137 |
> > > > > |
138 |
> > > > > |
139 |
> > > > > 2006/3/14, tvali <qtvali@×××××.com>: |
140 |
> > > > > |
141 |
> > > > > > 2006/3/14, Simon Stelling <blubb@g.o>: |
142 |
> > > > > > |
143 |
> > > > > > > tvali wrote: |
144 |
> > > > > > > > * Add package to "world" checking all dependencies, but not |
145 |
> > > emerging |
146 |
> > > > > > > > * Remove package from "world" without unmerging |
147 |
> > > > > > > |
148 |
> > > > > > > Uhm, why would you want that? |
149 |
> > > > > > > |
150 |
> > > > > > |
151 |
> > > > > > |
152 |
> > > > > > On my computer, building takes several hours on some packages. I have |
153 |
> > > used it in such way that it builds in several windows on the same time, but |
154 |
> > > i guess that that's not at all the best practice, especially with some |
155 |
> > > combinations of packages. So i would like to add all packages, seeing all |
156 |
> > > blocks and inter dependencies, then start building when ready (and go out of |
157 |
> > > home, when it builds, and be sure that it will do it's best when i'm away). |
158 |
> > > > > > |
159 |
> > > > > > |
160 |
> > > > > > > > * Save all important messages into file instead of beeping (i may |
161 |
> > > be away |
162 |
> > > > > > > > from home); optionally replay them at end of update |
163 |
> > > > > > > |
164 |
> > > > > > > elog can do this. |
165 |
> > > > > > |
166 |
> > > > > > |
167 |
> > > > > > Will check out. |
168 |
> > > > > > |
169 |
> > > > > > |
170 |
> > > > > > > > * When updating or installing new package, if something goes |
171 |
> > > wrong, still |
172 |
> > > > > > > > emerge other packages, which havent failed packages as |
173 |
> > > dependencies -- in my |
174 |
> > > > > > > > case, for example, when i do --update, for example, then the fact |
175 |
> > > that |
176 |
> > > > > > > > update of first package fails does not definitely mean that i dont |
177 |
> > > want to |
178 |
> > > > > > > > update others |
179 |
> > > > > > > |
180 |
> > > > > > > --resume |
181 |
> > > > > > |
182 |
> > > > > > |
183 |
> > > > > > I know --resume, but that's not what i meant. |
184 |
> > > > > > |
185 |
> > > > > > Imagine the situation: |
186 |
> > > > > > emerge -p package1 package2 |
187 |
> > > > > > |
188 |
> > > > > > part1 (needed by package1) |
189 |
> > > > > > part2 (needed by part3) |
190 |
> > > > > > part3 (needed by package2) |
191 |
> > > > > > part4 (needed by package2) |
192 |
> > > > > > part5 (needed by both package1 and package2) |
193 |
> > > > > > package1 |
194 |
> > > > > > package2 |
195 |
> > > > > > |
196 |
> > > > > > now i start "emerge package1 package2" and go to work (or sleep or |
197 |
> > > party or sauna). |
198 |
> > > > > > |
199 |
> > > > > > part2 fails -- some bug or misconfiguration. |
200 |
> > > > > > |
201 |
> > > > > > currently it means that when i came back home, i see that part1 is |
202 |
> > > built, but nothing more and 4-5 hours are actually just wasted. |
203 |
> > > > > > |
204 |
> > > > > > There should be a way to have all those built when i came home: |
205 |
> > > > > > |
206 |
> > > > > > part1 (needed by package1) |
207 |
> > > > > > part4 (needed by package2) |
208 |
> > > > > > part5 (needed by both package1 and package2) |
209 |
> > > > > > package1 |
210 |
> > > > > > |
211 |
> > > > > > There should be an error message listing all others. Also, i would add |
212 |
> > > them to world and then emerge so that --update would try to emerge them |
213 |
> > > again, asking me about all previously failed packages when i start it, if i |
214 |
> > > want to retry this time (yes, no, all, none). |
215 |
> > > > > > |
216 |
> > > > > > |
217 |
> > > > > > > -- |
218 |
> > > > > > > Kind Regards, |
219 |
> > > > > > > |
220 |
> > > > > > > Simon Stelling |
221 |
> > > > > > > Gentoo/AMD64 Developer |
222 |
> > > > > > > -- |
223 |
> > > > > > > gentoo-portage-dev@g.o mailing list |
224 |
> > > > > > > |
225 |
> > > > > > > |
226 |
> > > > > > |
227 |
> > > > > > |
228 |
> > > > > > |
229 |
> > > > > > |
230 |
> > > > > > -- |
231 |
> > > > > > tvali |
232 |
> > > > > > (e-mail: " qtvali@×××××.com"; msn: " qtvali@×××××.com"; |
233 |
> > > > > > icq: "317-492-912") |
234 |
> > > > > > |
235 |
> > > > > > Ühe eesti internetifirma lehel kohtasin tsitaati: |
236 |
> > > > > > If you don't do it excellently, dont do it at all. Because if it's not |
237 |
> > > excellent, it won't be profitable or fun, and if you're not in business for |
238 |
> > > fun or profit, what the hell are you doing here? |
239 |
> > > > > > Robert Townsend |
240 |
> > > > > |
241 |
> > > > > |
242 |
> > > > > |
243 |
> > > > > |
244 |
> > > > > -- |
245 |
> > > > > tvali |
246 |
> > > > > (e-mail: " qtvali@×××××.com"; msn: "qtvali@×××××.com"; |
247 |
> > > > > icq: "317-492-912") |
248 |
> > > > > |
249 |
> > > > > Ühe eesti internetifirma lehel kohtasin tsitaati: |
250 |
> > > > > If you don't do it excellently, dont do it at all. Because if it's not |
251 |
> > > excellent, it won't be profitable or fun, and if you're not in business for |
252 |
> > > fun or profit, what the hell are you doing here? |
253 |
> > > > > Robert Townsend |
254 |
> > > > |
255 |
> > > > |
256 |
> > > > |
257 |
> > > > -- |
258 |
> > > > tvali |
259 |
> > > > (e-mail: "qtvali@×××××.com"; msn: " qtvali@×××××.com"; |
260 |
> > > > icq: "317-492-912") |
261 |
> > > > |
262 |
> > > > Ühe eesti internetifirma lehel kohtasin tsitaati: |
263 |
> > > > If you don't do it excellently, dont do it at all. Because if it's not |
264 |
> > > excellent, it won't be profitable or fun, and if you're not in business for |
265 |
> > > fun or profit, what the hell are you doing here? |
266 |
> > > > Robert Townsend |
267 |
> > > |
268 |
> > > |
269 |
> > |
270 |
> > |
271 |
> > -- |
272 |
> > tvali |
273 |
> > (e-mail: "qtvali@×××××.com"; msn: "qtvali@×××××.com"; |
274 |
> > icq: "317-492-912") |
275 |
> > |
276 |
> > Ühe eesti internetifirma lehel kohtasin tsitaati: |
277 |
> > If you don't do it excellently, dont do it at all. Because if it's not |
278 |
> > excellent, it won't be profitable or fun, and if you're not in |
279 |
> > business for fun or profit, what the hell are you doing here? |
280 |
> > Robert Townsend |
281 |
> > |
282 |
> |
283 |
> |
284 |
> -- |
285 |
> tvali |
286 |
> (e-mail: "qtvali@×××××.com"; msn: "qtvali@×××××.com"; |
287 |
> icq: "317-492-912") |
288 |
> |
289 |
> Ühe eesti internetifirma lehel kohtasin tsitaati: |
290 |
> If you don't do it excellently, dont do it at all. Because if it's not |
291 |
> excellent, it won't be profitable or fun, and if you're not in |
292 |
> business for fun or profit, what the hell are you doing here? |
293 |
> Robert Townsend |
294 |
> |
295 |
|
296 |
|
297 |
-- |
298 |
tvali |
299 |
(e-mail: "qtvali@×××××.com"; msn: "qtvali@×××××.com"; |
300 |
icq: "317-492-912") |
301 |
|
302 |
Ühe eesti internetifirma lehel kohtasin tsitaati: |
303 |
If you don't do it excellently, dont do it at all. Because if it's not |
304 |
excellent, it won't be profitable or fun, and if you're not in |
305 |
business for fun or profit, what the hell are you doing here? |
306 |
Robert Townsend |
307 |
|
308 |
-- |
309 |
gentoo-portage-dev@g.o mailing list |