Towards replacing rpm + yum (0.1):

 - installer part:

    - pre install check; check that dirs can be created (no files where

      want to create dirs), move config files according to file

      flags. (.rpmnew etc)

    - run hooks; probably fork to shell and in the parent just do a

      write() of the hook section to a pipe to the shell.

    - store rpm headers for installed packages.

 - signed packages

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

   maybe not necessary, we can just add sections that augment the

   sections we want to add to (similar to how rpm has add versioned

   deps).

 - pipelined download and install; topo-sort packages in update set,

   pick one with all deps in the current set, add it to the current set

   and satisfy deps against update set => result: minimal update

   transaction.  Queue download and install/update transaction for the

   packages in the minimal set, start over.  This also makes the

   installation phase much more interruptible, basically just stop

   after a sub-transaction finishes.  As we keep the update set around

   as a target, we can restart if needed.  Probably don't need to, can

   just do a new update.  During a sub-transaction we should keep the

   target set (i.e. the current set to be) around as a lock file

   (system.repo.lock or so, see git) so that razor updates are

   prevented if the systems crashes during an update.

 Misc ideas:

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

 - transactions, proper recovery, make sure we don't poop our package

   database (no more rm /var/lib/rpm/__cache*).

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

 - 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?  Should be pretty small,

   especially if we don't have file checksums in metadata.  Filenames

   and properties are for the most part already present, typically just

   a version bump plus maybe tweaking a couple requires.  The upstream

   repo can store multiple incremental updates in one big file and

   provide an index file that maps updates for a given date (we should

   use repo-file checksums though) to a range in the file: Download the

   index file, search for a match for your latest rawhide.repo file,

   download range of updates that brings it up to date.

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

   files in rawhide.

 Bugs:

 - eliminate duplicate entries in package property lists.