BACKEND

   1 $Id$
   2
   3 Most package data is available via sleepycat databases. Those have been
   4 specifically crafted for efficient lookup, and reasonable times to generate
   5 them, so that both the daily cronjobs and the actual pagerequests take only a
   6 moderate amount of CPU and I/O
   7
   8 The only pages that are really generated staticly are the pages listing all
   9 packages in a given section.
  10
  11
  12 This is a brief overview of the available databases:
  13
  14 *********************************************************
  15 Generated by means of Packages.gz files:
  16 *********************************************************
  17
  18 | packages_small.db:
  19 |  key: packagename
  20 |  value: \0 separated tuples of "archive suite arch component section priority version shortdescription"
  21 |          (so you can split on spaces in 8 pieces, but need to not split further
  22 |          because shortdescription can have spaces)
  23   Notes: - maybe add did right before shortdescription?
  24                  - for each suite, newest package is shown first, and (suite,
  25                    architecture) is unique, the newest one is choosen. Once you find
  26                    the right suite, you know you've got the newest, once you found
  27                    your (suite,arch), you know you've found the only unique such entry
  28                  - The very first element is different (TODO: maybe should be
  29                    different DB then?), a \01 separated hash of suite -> provided-by,
  30                    like "suite1\01prov1 prov2\01suite2\01prov1"
  31
  32 | package_postfixes.db:
  33 |  key: a postfix string of a package name
  34 |  value: \0-separated list of prefixes that can preseed this postfix with '^'
  35 |         instead of the empty string in case a postfix happens to (also?) be
  36 |         a full package name
  37  Note: value can also be \01<decimal number>, meaning there were <decimal
  38  number> different packages with that postfix (always more than 100)
  39
  40 | packages_descriptions.db:
  41 |  key: "packagename version arch"
  42 |  value: a unique description id, did
  43
  44 | descriptions.txt:
  45 |  on each line:
  46 |    description with strange characters mangled for proper substring
  47 |    searching, linenumber being the did
  48
  49 | descriptions.db:
  50 |  key: did
  51 |  value: description, first line being short, the rest being long [no
  52 |            newline transformation]
  53
  54 | descriptions_packages.db:
  55 |  key: did
  56 |  value: one or more occurances of: "packagename version arch", separated by \0
  57
  58 | packages_all_$suite.db:
  59 |  key: "packagename arch version"
  60 |  value: \0-separated pairs of key\0value items, with key being always
  61 |         lowercase and having most normal Packages.gz entries, except:
  62 |         - source: always available, contains straight source package name
  63 |         - description: has did (description id) only
  64 |         - archive: notes source archive
  65
  66 | sources_packages.db:
  67 |  key: sourcepackagename
  68 |  value: \0 separated tuples of "archive suite package version arch"
  69
  70   Note: this also comes from the Packages.gz files, and not from Sources.gz
  71   files, for accuracy.
  72
  73 *********************************************************
  74 Generated by means of Sources.gz files:
  75 *********************************************************
  76
  77 | sources_small.db:
  78 |  key: sourcename
  79 |  value: \0 separated tuples of "archive suite component section priority version"
  80
  81 | source_postfixes.db:
  82 |  key: a postfix string of a source name
  83 |  value: \0-separated list of prefixes that can preseed this postfix with '^'
  84 |         instead of the empty string in case a postfix happens to (also?) be
  85 |         a full package name
  86  Note: value can also be \01<decimal number>, meaning there were <decimal
  87  number> different packages with that postfix (always more than 100)
  88
  89 | sources_all_$suite.db:
  90 |  key: "archive suite sourcename"
  91 |  value: \0-separated pairs of key\0value items, with key being always
  92 |         lowercase and having most normal Sources.gz entries, except:
  93 |         - files: \01 separated list of "md5 size filename"
  94   Note: different key from packages_all, is that needed?
  95
  96 *********************************************************
  97 Generated by means of Contents-$arch.gz files:
  98 *********************************************************
  99
 100 This one is tricky, because it deals with about 1G of raw uncompressed data
 101 per suite. Not all data is updated every day though, so dealing with that
 102 efficiently pays off.
 103
 104 Each sourcefile will create a filelists_$suite_$arch.db, with prefix
 105 compression. The last updated one will have a symlink from _all.db to it, to
 106 help filelist queries for 'all' packages.
 107
 108 reverse_$suite_$arch.txt will be the reversed pathnames for that file,
 109 lowercased, sorted, with packagename:arch following it.
 110
 111 For each suite, the suite-wide indices can then be updated by reading the 11
 112 or so reverse_$suite_$arch.txt in sorted order with sort -m. Same pathnames
 113 can be put together, and stored in reverse_$suite.db; filenames are then also
 114 incidently coming by grouped uniquely (but reverse sorted, not normal sorted),
 115 and can be written out linearly to filenames_$suite.txt
 116