I would suggest a different way of updates. When you manually change portage tree, you have to make an overlay. Overlay, as it's updated and managed by human being, will be always small (unless someone makes a script, which creates million overlay updates, but I dont think it would be efficient way to do anything). So, when you search, you can search Portage tree with index, which is updated with --sync and then search overlay, which is small and fast to search anyway. Overlay should not have index in such case. If anyone is going to change portage tree by hand, those changes will be lost with next --sync and thus noone should do it anyway - this case should not be considered at all.
Tambet - technique evolves to art, art evolves to magic, magic evolves to just doing. 2008/12/1 Emma Strubell <[EMAIL PROTECTED]> > Thanks for the clarification. I was planning on forcing an update of the > index as a part of emerge --sync, and implementing a command that would > update the search index (leaving it up to the user to update after making > any manual changes to the portage tree). That way the search index should > always be up-to-date when emerge -s is called. It does make sense for the > update upon --sync to be optional, but I guess I don't see why the update > should always be SO slow. Of course the first population of the tree will > take quite a while, but assuming regular (daily?) --syncs (and therefore > updates to the index), subsequent updates shouldn't take very long, since > there will only be a few (hundred?) changes to be made to the tree. > > And I do plan on using a pickling the search tree :] > > Emma > > > On Mon, Dec 1, 2008 at 12:52 PM, Zac Medico <[EMAIL PROTECTED]> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Emma Strubell wrote: >> > I completely forgot about Google's Summer of Code! Thanks for reminding >> me. >> > Hopefully I won't forget again by the time summer rolls around, >> obviously I >> > wouldn't mind getting a little extra money for doing something I'd do >> for >> > free anyway. >> > >> > On a more related note: What, exactly, does porttree.py do? And am I >> correct >> > in thinking that my suffix tree(s) should somewhat replace porttree.py? >> Or, >> > should I be using porttree.py in order to populate my tree? >> >> You should use portree.py to populate it. Specifically, you should >> use portdbapi.aux_get() calls to access the package metadata that >> you'll need, similar to how the code in the existing search class >> accesses it. >> >> > I think I have >> > the suffix tree sufficiently figured out, I'm just trying to determine >> > where, exactly, the tree will fit in to the portage code, and what the >> best >> > way to populate it (with package names and some corresponding metadata) >> > would be. >> >> There are there possible times that I imagine a person might want to >> populate it: >> >> 1) Automatically after emerge --sync. This should not be mandatory >> since it will be somewhat time consuming and some users are very >> sensitive about --sync time. Note that FEATURES=metadate-transfer is >> disabled by default in the latest versions of portage, specifically >> to reduce --sync time. >> >> 2) On demand, when emerge --search is invoked. The calling user will >> need appropriate file system permissions in order to update the >> search index. >> >> 3) On request, by calling a command that is specifically designed to >> generate the search index. This could be a subcommand of emaint. >> >> For the index file format, it would be simplest to use a python >> pickle file, but you might choose another format if you'd like the >> index to be accessible without python and the portage API (probably >> not necessary). >> - -- >> Thanks, >> Zac >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.9 (GNU/Linux) >> >> iEYEARECAAYFAkk0JFAACgkQ/ejvha5XGaONDACgixnmCh9Ei6MyUGIZXpiFt7F2 >> gqMAoOhf5H2uZHB7xhjecOcL0G3w/cqR >> =hFNz >> -----END PGP SIGNATURE----- >> >> >
