| 1 |
Thanks for the clarification. I was planning on forcing an update of the |
| 2 |
index as a part of emerge --sync, and implementing a command that would |
| 3 |
update the search index (leaving it up to the user to update after making |
| 4 |
any manual changes to the portage tree). That way the search index should |
| 5 |
always be up-to-date when emerge -s is called. It does make sense for the |
| 6 |
update upon --sync to be optional, but I guess I don't see why the update |
| 7 |
should always be SO slow. Of course the first population of the tree will |
| 8 |
take quite a while, but assuming regular (daily?) --syncs (and therefore |
| 9 |
updates to the index), subsequent updates shouldn't take very long, since |
| 10 |
there will only be a few (hundred?) changes to be made to the tree. |
| 11 |
|
| 12 |
And I do plan on using a pickling the search tree :] |
| 13 |
|
| 14 |
Emma |
| 15 |
|
| 16 |
On Mon, Dec 1, 2008 at 12:52 PM, Zac Medico <zmedico@g.o> wrote: |
| 17 |
|
| 18 |
> -----BEGIN PGP SIGNED MESSAGE----- |
| 19 |
> Hash: SHA1 |
| 20 |
> |
| 21 |
> Emma Strubell wrote: |
| 22 |
> > I completely forgot about Google's Summer of Code! Thanks for reminding |
| 23 |
> me. |
| 24 |
> > Hopefully I won't forget again by the time summer rolls around, obviously |
| 25 |
> I |
| 26 |
> > wouldn't mind getting a little extra money for doing something I'd do for |
| 27 |
> > free anyway. |
| 28 |
> > |
| 29 |
> > On a more related note: What, exactly, does porttree.py do? And am I |
| 30 |
> correct |
| 31 |
> > in thinking that my suffix tree(s) should somewhat replace porttree.py? |
| 32 |
> Or, |
| 33 |
> > should I be using porttree.py in order to populate my tree? |
| 34 |
> |
| 35 |
> You should use portree.py to populate it. Specifically, you should |
| 36 |
> use portdbapi.aux_get() calls to access the package metadata that |
| 37 |
> you'll need, similar to how the code in the existing search class |
| 38 |
> accesses it. |
| 39 |
> |
| 40 |
> > I think I have |
| 41 |
> > the suffix tree sufficiently figured out, I'm just trying to determine |
| 42 |
> > where, exactly, the tree will fit in to the portage code, and what the |
| 43 |
> best |
| 44 |
> > way to populate it (with package names and some corresponding metadata) |
| 45 |
> > would be. |
| 46 |
> |
| 47 |
> There are there possible times that I imagine a person might want to |
| 48 |
> populate it: |
| 49 |
> |
| 50 |
> 1) Automatically after emerge --sync. This should not be mandatory |
| 51 |
> since it will be somewhat time consuming and some users are very |
| 52 |
> sensitive about --sync time. Note that FEATURES=metadate-transfer is |
| 53 |
> disabled by default in the latest versions of portage, specifically |
| 54 |
> to reduce --sync time. |
| 55 |
> |
| 56 |
> 2) On demand, when emerge --search is invoked. The calling user will |
| 57 |
> need appropriate file system permissions in order to update the |
| 58 |
> search index. |
| 59 |
> |
| 60 |
> 3) On request, by calling a command that is specifically designed to |
| 61 |
> generate the search index. This could be a subcommand of emaint. |
| 62 |
> |
| 63 |
> For the index file format, it would be simplest to use a python |
| 64 |
> pickle file, but you might choose another format if you'd like the |
| 65 |
> index to be accessible without python and the portage API (probably |
| 66 |
> not necessary). |
| 67 |
> - -- |
| 68 |
> Thanks, |
| 69 |
> Zac |
| 70 |
> -----BEGIN PGP SIGNATURE----- |
| 71 |
> Version: GnuPG v2.0.9 (GNU/Linux) |
| 72 |
> |
| 73 |
> iEYEARECAAYFAkk0JFAACgkQ/ejvha5XGaONDACgixnmCh9Ei6MyUGIZXpiFt7F2 |
| 74 |
> gqMAoOhf5H2uZHB7xhjecOcL0G3w/cqR |
| 75 |
> =hFNz |
| 76 |
> -----END PGP SIGNATURE----- |
| 77 |
> |
| 78 |
> |
Archives