Bug 26532 - esearch - Replacement for 'emerge search' with search-index
|
Bug#:
26532
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: enhancement
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: dev-portage@gentoo.org
|
Reported By: davidpeter@web.de
|
|
Component: Ebuilds
|
|
|
URL:
http://david-peter.de/esearch
|
|
Summary: esearch - Replacement for 'emerge search' with search-index
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2003-08-13 02:43 0000
|
esearch is a small python script to search the portage tree. The package
includes 'eupdatedb', which will generate an index-file with package-names,
descriptions, homepage etc. After the index is compiled, you can search with
'esearch'. It behaves exactly like 'emerge search'.
David
This not only works for me, it's also increadible--
time emerge -s moz
real 0m1.736s
user 0m1.524s
sys 0m0.112s
time esearch moz
real 0m0.135s
user 0m0.121s
sys 0m0.009s
time emerge -S browser
real 0m39.918s
user 0m26.439s
sys 0m1.840s
time esearch -S browser
real 0m0.150s
user 0m0.135s
sys 0m0.005s
I think this should replace emerge -s and emerge -S
it takes a while to compile the index
but DAMN its fast :-)
rather than doing this i think we should just work on moving all of portage
over
to a compiled db format (Bug 20330)
I think esearch could, at least, provide a temporary solution. I don't think
that the portage db will move to a compiled format very soon, although there
are even some implementations (http://portagesql.breakmygentoo.net/).
Or are there already some plans to change the format of the portdb?
Furthermore, esearch has some additional functionality (the --compact switch)
and maybe I'll add some more in the next versions.
But anyway, if the portage devs are planning to move the portdb to a "real" db,
it makes no sense to add esearch to the portage-tree.
Thanks,
David
There is one implement for using db in bug 26447
Karl take a look at this for gentoolkit? Looks interesting.
Portage will be using dbm eventually, but this looks like a
good "now" solution.
David, I love this esearch thing. The only brokenness I've discovered is:
esearch mysql++
doesn't exit cleanly because I guess it assumes it to be a regex or something.
Also -- eupdatedb takes a long long time -- any way to speed that up?
Thanks for your comments. I've fixed this "bug" with mysql++. I say "bug",
because it isn't really a wrong behaviour, but it's a wrong regex. In fact,
emerge -s fixes this regex and adds a slash: ++ -> \+\+.
I've done some profiling and found out some functions, that are really slow.
I'll try to work on eupdatedb, to improve speed.
You may try out version 0.3.1. Just copy the esearch-0.3.0.ebuild to
esearch-0.3.1.ebuild, and "emerge esearch".
I would be really happy if it would be added to portage, or to gentoolkit.
PS: eupdate *is* slow compared to other search-scripts (like fastsearch for
example), but it has the advantage, that it uses the data directly from
portage(.py) so you can be sure, it shows you the right version, description
and homepage (e.g. fastsearch cannot evaluate eclasses)
I added this to portage, the 0.4.0 version is great.
Hi,
Thanks a lot, Seemant.
But I've got a - maybe stupid - question: Where did my announce of esearch-0.4.0 go? The new ebuild is also missing. However, it seems as if you had the chance to read it, before it disappeared :-)
David
------- Additional Comments From shark@phpwelt.com 2003-18-09 07:43 EST
-------
Hi,
After a bit of experimenting today, I found out a weak point in eupdatedb. The
little mistake I made, was to write the whole package database into the memory,
and then write all at once to the index-file. Now I changed the code and it
writes the packages directly into the file. This behaviour does not only save
free memory, but it really speeds eupdatedb up alot. Now it runs about 10 times
faster on my computer.
I also added a ChangeLog and 2 other features. I'll attach the new ebuild
esearch-0.4.0.ebuild.
Thanks for your interest.