1 |
On Tue, 2006-14-03 at 16:33 +0200, tvali wrote: |
2 |
> I did think about it now and it seems to me that probably it would be |
3 |
> much faster if esearch is not just another package, but part of |
4 |
> portage. |
5 |
> |
6 |
> I mean -- functions of portage, which query db, should use esearch |
7 |
> index wherever they need information, which exists in that index. |
8 |
> |
9 |
> As much as i can understand, /var/cache/edb/ contains esearch database |
10 |
> in many files and esearchdb.py is search index as python script. |
11 |
> |
12 |
|
13 |
I have been considering adding the esearch database and code into |
14 |
porthole, or possibly a modified version of it. |
15 |
|
16 |
> I think that SQL functions for searching and other things are maybe |
17 |
> not much faster than py (as py seems to be fast enough, at least if |
18 |
> there are more important things to do), but simpler to use. Therefore |
19 |
> i think that rewriting the whole thing with SQL support may be still |
20 |
> better. |
21 |
> |
22 |
> I will make it clear for me, what those emerge db functions do and |
23 |
> still try to do something, what connects them to SQL. |
24 |
> |
25 |
|
26 |
If I recall, (there has been lots of discussion about converting portage |
27 |
to use databases, just check the mail archives and forum) portage |
28 |
already has sqlite support, but is not yet used. Sqlite is smaller and |
29 |
has less dependencies than mysql. |
30 |
|
31 |
|
32 |
> Anyway, i am still interested, is there some code or other |
33 |
> documentation about how portage works, especially how it keeps it's |
34 |
> data? |
35 |
|
36 |
Also, many of the features you talked about are already implemented in |
37 |
porthole, such as continuing after a failed package, filtering out |
38 |
warnings, important messages, etc.. |
39 |
|
40 |
Check it out. |
41 |
|
42 |
-- |
43 |
Brian <dol-sen@×××××.net> |
44 |
|
45 |
-- |
46 |
gentoo-portage-dev@g.o mailing list |