TODO

   1 search_packages:
   2 - all searches:
   3   - Display "$pkg ($section) shortdesc from stable (or if not available, testing, unstable, ...)"
   4     tersely on one line each, with "#foo" links to what's currently displayed.
   5   - The 'extended' can maybe also have full descriptions then (maybe add did
   6         to _small.db?)
   7   - Unify exact & subword -- reduce naming confusion with 'exact' meaning
   8         either "exactly the same" or "full word"
   9   - When doing substring searches, hilight with html backgroup color (css of
  10         course) the search term
  11 - exact package searches
  12 - substring searches on packages:
  13   - don't allow whitespace in it, warn when people use common wildcards like
  14         *, ?, ^, $ (not possible)
  15   - When overflow, iterate the first couple of packages that *start* with the
  16         substring, if any? Maybe list those first, and only then real substring
  17         search?
  18   - In db, add "abc: too many matches" to postfixes when there's a "abcd: 90
  19         matches" and abce: 90 matches"
  20
  21 - fulltext search:
  22   - in results, show full descriptions, so one sees what's being matched?
  23
  24 - backend:
  25   - Ensure that in _small.db, newest version for each suite is first,
  26         show_package relies on that. So foreach suite, 'newest entry', and only
  27         then, all the other entries
  28
  29 search_contents:
  30 - regain section (main/contrib/non-free) information? It is currently
  31    not available at all.
  32
  33 Static pages:
  34 - try to make it faster
  35
  36 General:
  37 - Try to break everything with empty/short searches
  38 - Check for case sensitive consistency
  39 - Fix assumption that archive doesn't show up in any url, consistency-fy
  40   dealing with archives of a different set than (us, non-us, security)
  41 - grep -ri fixme
  42 - searchon=all -> searchon=descriptions?
  43 - quicksearch box: copy parameters of current search (exact,suite,arch,etc),
  44   or rather, always use defaults? Both have their pro&cons... former is more
  45   obscure, but otoh, for typo fixing more appropriate.
  46   Maybe best of both worlds is 'modify search' below results, where you can
  47   generalize/specificy arch, etc etc?
  48 - In Search.pm, make sure read_entry_small only scans a bit, and not all --
  49   once you have #max_nr_of_suites, you know you won't find the queried suite
  50   anymore, so search further is futile. Maybe the backend could even add a
  51   marker, ignored by read_entry_all, but understood by read_entry_small, that
  52   indicates end of $res2 and start of $res3
  53 - Store in db \1-separated, and split on that, instead of the more fragile
  54   '/, /' split
  55 - Fields we don't handle in any way currently:
  56   Conflicts
  57   Replaces
  58   Enhances
  59   Origin    -- not needed
  60   Bugs      -- not needed
  61   Task
  62   Python-Version(s) -- not needed
  63
  64 Cron:
  65 - Verify Release files
  66 - refactorize 100syncarchive* so that there is not so much copied code
  67
  68 Missing pieces from old code:
  69  - search_packages result parser?
  70    reportbug in sarge is completly broken in this regard anyway AFAICT
  71    reportbug in etch works as long as there is the exact hit but
  72    breaks once there is more than one hit