Good point. I may just ignore overlays completely because 1) I don't use them and 2) does anyone really need to search an overlay anyway? aren't any packages added via an overlay added deliberately?
On Mon, Dec 1, 2008 at 4:52 PM, Tambet <[EMAIL PROTECTED]> wrote: > 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----- >>> >>> >> >
