search_packages.pl: - all searches: - Display "$pkg ($section) shortdesc from stable (or if not available, testing, unstable, ...)" tersely on one line each, with "#foo" links to what's currently displayed. - The 'extended' can maybe also have full descriptions then (maybe add did to _small.db?) - Unify exact & subword -- reduce naming confusion with 'exact' meaning either "exactly the same" or "full word" - When doing substring searches, hilight with html backgroup color (css of course) the search term - exact package searches - substring searches on packages: - don't allow whitespace in it, warn when people use common wildcards like *, ?, ^, $ (not possible) - When overflow, iterate the first couple of packages that *start* with the substring, if any? Maybe list those first, and only then real substring search? - In db, add "abc: too many matches" to postfixes when there's a "abcd: 90 matches" and abce: 90 matches" - fulltext search: - Max 100 results - Better exact=1 performance by indexing per word? - drop case-sensitive from options, descriptions.txt all lowercase and without punctuation, such that instead of =~ //, indexof can be used - in results, show full descriptions, so one sees what's being matched? - backend: - Ensure that in _small.db, newest version for each suite is first, show_package relies on that. So foreach suite, 'newest entry', and only then, all the other entries Static pages: - try to make it faster General: - Try to break everything with empty/short searches - Check for case sensitive consistency - Fix assumption that archive doesn't show up in any url, consistency-fy dealing with archives of a different set than (us, non-us, security) - grep -ri fixme - searchon=all -> searchon=descriptions? - quicksearch box: copy parameters of current search (exact,suite,arch,etc), or rather, always use defaults? Both have their pro&cons... former is more obscure, but otoh, for typo fixing more appropriate. Maybe best of both worlds is 'modify search' below results, where you can generalize/specificy arch, etc etc? - In Search.pm, make sure read_entry_small only scans a bit, and not all -- once you have #max_nr_of_suites, you know you won't find the queried suite anymore, so search further is futile. Maybe the backend could even add a marker, ignored by read_entry_all, but understood by read_entry_small, that indicates end of $res2 and start of $res3 Missing pieces from old code: - DDTP support (but without a working DDTP I will not invest any time in that) - search_packages compatibility (we should at least ensure we don't break sarge's reportbug)