Towards replacing rpm + yum (0.1):

- installer part

- rpm file parser, create repo command

- conflicts, obsoletes

- versions in depsolving

- signed packages

- merge file lists when merging package sets

- download (libcurl?)

- figure out how to canonically represent empty string... ~0?

- space calculation before transaction, but ideally, do a number of
  smaller transactions.

- pre-link changing binaries and libs on disk screwing up checksum?

- nail down byte-order and word sizes of repo file.

- version the sections in the file, put the element size in the header
  so we can add stuff to elements in a backwards compatible way.

Misc ideas:

- eliminate duplicate entries in package property lists.

- 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.

- 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*).

- 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).

- test suite should be easy, just keep .repo files around and test
  different type of upgrades that way (obsoletes, conflicts, file
  conflicts, file/dir problems etc).  Or maybe just keep a simple file
  format ad use a custom importer to create the .repo files.

- pipelined download and install; download is network bound, install
  is disk bound.  Start installing once we have self-contained set of
  packages.  Install in reverse topo-sort order.  Interruptible
  installation; stops at nearest checkpoint.

- split out hash table code from importer, make the merger use just
  the hash table.

- try to clean up the

	do { ... } while (((e++)->name & RAZOR_ENTRY_LAST) == 0);

  idiom for iteration of directories.

- overlay package sets?  mount a read-only /usr over nfs or from the
  virt-host and have a local package set overlaid over the read-only
  one.  shouldn't need new features in the core package set data
  structure, but should be just conventions on top.  we have the base
  package set from the r/o system, the overlay set from the local
  system and we can have an effective package set which is the merge
  of everything from the overlay into the base set.  the effective set
  is easy to compute and we could do it on the fly or cache it.  or
  maybe the effective set is the on-disk representation and the
  overlay can be computed when needed, we just keep a link back to the
  base.

- incremental rawhide repo updates? instead of downloading 10MB zipped
  repo every time, download a diff repo?

- use hash tables for dirs when importing files to avoid qsorting all
  files in rawhide.

- corner cases such as no files/properties in repo etc segfault.