- keep history of installed packages/journal of package transaction,
  so we can roll back to yesterday, or see what got installed in the
  latest yum update.

- we build a cache of the currently installed set to service
  dependency inquiries fast:

	map from property to pkg (as hash) providing it
	map from property to pkgs requiring it
	map from pkg name to manifest
	map from string to string pool index

	no implicit provides? not even pkgname?

- properties are strings, stored in a string table

- on disk maps are binary files of (string table index, hash) pairs

- at run time, we mmap the map, and keep changes in memory in a splay
  tree or similar.  if searching the splay tree fails we punt to the
  mmap.  once the transaction is done, we merge the map and the splay
  tree and write it back out.

- the on-disk string pool is sorted and we keep a list of indices into
  the string pool in sorted order so we can bsearch the list with a
  string to get its string pool index.  maybe a hash table is better,
  less I/O as we will expect to find the string within the block we
  look up with the hash function.

- represent all files as a breadth first traversal of the tree of all
  files.  each entry has its name (string pool index), the number of
  immediate children, total number of children, and owning package.
  for files both these numbers are zero.  a file is identified by its
  index in this flattened tree.

  to get the file name from an index, we search through the list.  by
  summing up the number of children, we know when to skip a directory
  and when to descend into one.  as we go we accumulate the path
  elements.

  hmm, dropping number of immediate children and using a sentinel drops
  a word from every entry.

- signed pkgs

- gzip repository of look-aside pkg xml files somehow?

- transactions, proper recovery, make sure we don't poop our package
  database (no more rm /var/lib/rpm/__cache*).

- no external dependencies, forget about bdb, sqlite.  It's *simple*
  and we need to control the on-disk format for these tools.

- diff from one package set to another answers: "what changed in
  rawhide between since yesterday?"

- rewrite qsort and bsearch that doesn't require global context var
  and can output a map describing the permutaion.

- use hash table for package and property lists so we only store
  unique lists (like for string pool).

- use existing, running system as repo; eg

	razor update razor://other-box.local evince

  to pull eg the latest evince and dependencies from another box.  We
  should be able to regenerate a rzr pkg from the system so we can
  reuse the signature from the originating repo.

- Ok, maybe the fastest package set merge method in the end is to use
  the razor_importer, but use a hash table for the properties.  This
  way we can assign them unique IDs immediately (like tokenizing
  strings).